July 2003 - Oberon - mailman3.inf.ethz.ch

Re (3): Re. [Oberon] Bluebotte and DSL Problems
by frey＠inf.ethz.ch 10 Jul '03

10 Jul '03

> after further experiments I found that connection to the Strato > FTP server also worked with DSL. PWD was ok also. > What didn't work was Dir. So I guess it's some timing problem. Maybe it has to do with active FTP connections. The Oberon FTP client tries to do active FTP, requiring another connection from outside. Some firewalls/dsl routers don't accept this. > Perhaps DSL is filling a buffer too fast for FTP or Mail to > read it. TCP should be resistant against this kind of problems. You could try to reduce the MTU since it is not dynamically adapted but it should not be needed. If you want to try : Desktops.OpenDoc AosRTL8139.Mod ~ Search: NEW(d, AosNet.LinkEthernet, MaxETHFrameSize - 14, 6); Replace with e.g. . NEW(d, AosNet.LinkEthernet, 512, 6); Recompile, restart. (If it helps, you can inc the value 512 as long as it still helps ;-) But I don't think so :-( ) --Thomas

1 0

Re (2): Re. [Oberon] Bluebotte and DSL Problems
by edgar＠edgarschwarz.de 09 Jul '03

09 Jul '03

Hi, after further experiments I found that connection to the Strato FTP server also worked with DSL. PWD was ok also. What didn't work was Dir. So I guess it's some timing problem. Perhaps DSL is filling a buffer too fast for FTP or Mail to read it. Because for Mail also it looks like I get some fragments. Thanks for your ideas. peter_easthope(a)gulfnet.sd64.bc.ca wrote: > cg> ... ease of maintainability. > That is why I spent a few weeks studying the > PPP protocols and many hours improving the > logging facilities in Oberon PPP. Several > tasks continue, with DNS negotiation being > the most significant. I just downloaded your PPP files. In the next couple of days I will have a look at your changes. Perhaps I can make a new release then and upload it to http:/webdav.ethz.ch/ppp/ Cheers, Edgar -- edgar(a)edgarschwarz.de "http://www.edgarschwarz.de" "http://www.edgar-schwarz.de/forum/oberon" Running Active Oberon Make it as simple as possible, but not simpler. Albert Einstein

1 0

Re: Re. [Oberon] Bluebotte and DSL Problems
by peter_easthope＠gulfnet.sd64.bc.ca 09 Jul '03

09 Jul '03

Chris, Edgar & others, cg> ... all playing with 'visual effects' and using MS connectivity. FWIIW every system I connect to the Internet is Debian Linux or Oberon. cg> ... ease of maintainability. That is why I spent a few weeks studying the PPP protocols and many hours improving the logging facilities in Oberon PPP. Several tasks continue, with DNS negotiation being the most significant. cg> ... MS patented authentication (vs. CHAP, PAP) which some ISPs use. Apathy facilitates domination. The best antidote to this and similar predicaments is our work to keep Oberon/AOS viable. You know the cliche, "hang in there". Regards, P. http://carnot.pathology.ubc.ca/

1 0

Re. [Oberon] Bluebotte and DSL Problems
by eas-lab＠absamail.co.za 09 Jul '03

09 Jul '03

Edgar wrote: > I got DSL on last saturday. It sort of works with Bluebottle. > There are only some funny problems. > Connecting to a bluebottle.ethz.ch FTP server works fine with DSL and PPP. > Connecting to my Strato FTP account fails with DSL but works with PPP. > Sending mail to post.strato.de works with DSL and PPP. > > Receiving mail from post.strato.de fails with DSL ('No new mail' even if > there is) Receiving mail from post.strato.de works with DSL and > Windows/Netscape. > > Any experiences or ideas ? Yes. You have to start with the appropriate paradigm; which is NOT: "I tested it (on my system), so it's OK". My previous posts mentioned:----- * when I changed ISP, TextMail.<command> no longer worked. I had to patch the source code to remove an assumption, which usually worked for most systems, but was not per RFC. * Mail.Panel V2.3.2 StandAlone would not connect to my (then) ISP, nor V2.3.6 DOSbased; but Ver 2001 would. There are subtle timing aspects involved. Remember that the n-o box, the modem, the telco channel and the ISP are all FSMs. There are many posibilities to go wrong in the combination. ---- Yesterday I was reading on the ppp NewsGroup, about the MS patented authentication (vs. CHAP, PAP) which some ISPs use. ---- I believe that the correct method of 'managing the chaos' is to acknowledge the lack of certainty and design the code/system for ease of maintainability. Admittedly - easier said than done. Complexity/uncertainty is appropriately handled with statistical approaches. A relevant statistic is that few users use/test/confirm ETH-oberon's internet facilities - they are all playing with 'visual effects' and using MS connectivity. -- Chris Glur.

1 0

Re: [Oberon] Bluebotte and DSL Problems
by peter_easthope＠gulfnet.sd64.bc.ca 09 Jul '03

09 Jul '03

Edgar, Sorry, I don't have DSL. es> Sending mail to post.strato.de works with DSL and PPP. es> Receiving mail from post.strato.de fails with DSL Presumeably you send mail with SMTP. Is mail received with SMTP or with POP? The general picture is a collection of small problems as I have found with FAT file access and with PPP. As Chris has said, all we need is many more people chasing down bugs. What about turning on logging and tracing through the log as both of us have done with PPP? Regards, Peter E. http://carnot.pathology.ubc.ca/

1 0

Bluebotte and DSL Problems
by edgar＠edgarschwarz.de 08 Jul '03

08 Jul '03

Hi, I got DSL on last saturday. It sort of works with Bluebottle. There are only some funny problems. Connecting to a bluebottle.ethz.ch FTP server works fine with DSL and PPP. Connecting to my Strato FTP account fails with DSL but works with PPP. Sending mail to post.strato.de works with DSL and PPP. Receiving mail from post.strato.de fails with DSL ('No new mail' even if there is) Receiving mail from post.strato.de works with DSL and Windows/Netscape. Any experiences or ideas ? Edgar -- edgar(a)edgarschwarz.de "http://www.edgarschwarz.de" "http://www.edgar-schwarz.de/forum/oberon" Running Active Oberon Make it as simple as possible, but not simpler. Albert Einstein

1 0

Re: [Oberon] Port of XML to Native/Plugin Oberon (was Re: Antwort: DAV porting question)
by Edgar＠EdgarSchwarz.de 08 Jul '03

08 Jul '03

John Drake <jmdrake_98(a)yahoo.com>: > Ok. Here's the code. > http://freezope2.nipltd.net/jmdrake/Oberon/xmlport.zip Thanks John, I will give it a try on the weekend. Regards, Edgar -- edgar(a)edgarschwarz.de "http://www.edgarschwarz.de" "http://www.edgar-schwarz.de/forum/oberon" Running Active Oberon Make it as simple as possible, but not simpler. Albert Einstein

5 10

Re (2): [Oberon] Trap in storing a FAT file.
by eas-lab＠absamail.co.za 07 Jul '03

07 Jul '03

Chris, cg> ... the WHILE terminating condition is expected to occur before the linked-list finds it's tail at c.next = NIL. cg> I'm guessing that it does NOT ! I'm guessing that your machine is testing (which was not done before) that c.next = NIL occurs before the WHILE terminating condition is satisfied. > Do you see a reason why this would happen > only on one specific machine and only in > half of the store attempts? These > circumstances suggest a low level hardware > problem---ATADisks.Mod for example. Well, without looking at the code again, because I don't have the trap info, I remember that the 'while loop' had a 2 or 3 variable exit condition. Quiet complex. Remember every IDE is unique, when in use, I.e. which sectors are used. And each run will use a different set of sectors. There's no way that combinations can be tested. Is your partition getting towards filled up ? re. ATADisks.Mod , my experience of the trap facility is that it is reliable in showing the last few procedures executed before the trap. And it show no ATADisks.Mod problem. Are you using 'StandAlone' i.e. non-DOSbased/Linuxbased ? Can you try onother partion, or other IDE ? At one stage I used to swap my 5 IDEs between the 2 machines is if they were floppies - it's no big deal. I always boot via floppy - DOS, Linux, n-o. as cg> Compiler.Compile *\f Will have to try that during the weekend. ============= *** later: cg> I'm guessing that your machine is testing (which was not done before) that c.next = NIL occurs before the WHILE terminating condition is satisfied. cg> Compiler.Compile *\f > Sure enough, the exection error is in this statement in > OFSFATVolumes.AssignDirectoryEntry. > > WHILE (c.type # dcSentinel) & > ((c.type # dcFree) OR (c.entry.dirInfo.num < direntry.dirInfo.num)) > DO p := c; c := c.next END; > > Seems I need to make a comprehensive study of installable file > systems and FAT. For now, this is the Kernel.Log after turning > on Trace and Detail in the module (and recompiling and > reloading of course). OFSFATVolumes should have written a > raft of information which isn't there. Enough for now. I'm guessing that you have just got an unlucky combination that tests the trap condition. Or many files ? I don't use the FAT facility very much. Without making a deep study of the FAT structure it could be a big job to fix it. If we had a bigger user-base and better organisation, your much appreciated task of locating the fault would be done, and the team that specialises in FAT would just quickly fix it. That's how linux works. > TRAP -14 PC Native 05.01.2003 > CS:=0000001B DS:=00000020 ES:=00000020 SS:=00000023 CR0=80040031 > FPS=00000000 > EIP=0002B243 ESI=00377748 EDI=003E3324 ESP=0011E280 CR2=00000000 > SBT=0012001C > EAX=00000000 EBX=00000000 ECX=003DAC4C EDX=00000003 CR3=0009D000 > KFL=00003246 > EBP=0011E298 FS:=00000000 GS:=00000000 ERR=00000004 CR4=00000000 > TCK=0000C878 > EFLAGS=00013293 (OCPAZS=010101 IT=10 D=0 IOPL=11 NT=0 AC,VM,RF=001) > OFSFATVolumes PC=22443, OFSFATVolumes PC=24169, OFSFATFiles PC=2781, OFS > PC=4688, > Files PC=2024, ET PC=14016, ET PC=14672, ET PC=15089, Oberon PC=4860, > TextFrames PC=12027, ... Where does this come from ?!? -- Chris Glur.

1 0

Re.[Oberon] Bug Report/Survey
by eas-lab＠absamail.co.za 07 Jul '03

07 Jul '03

Aubrey McIntosh write:- (We would appreciate if you take some time and send us some feedback. Fill in the form below and use the Oberon mailer to mail this document. Also feel free to make any changes you like. Thank you. ). !! How much unintended traffic will this create ? Hi Oberon Developers, I found the following problem/have the following suggestion. My Name: Chris Glur My Organization: Semi retired Problem/Suggestion: User base too small; dependant on few contributors User Survey (Optional): Oberon satisfaction rating (0 - 100): <--compared to what ? Satisfied=dead I am using: Windows 3.1 <--- DOSbased n-o & view *.ps, *.pdf ? Windows for Workgroups Windows 95 Windows 98 Windows NT 3.x Windows NT 4.x Windows 2000 MacOS 6.x MacOS 7.x MacOS 8.x Linux <--- seldom for LNO Native Oberon for PC <--- continually Amount of RAM: 8MB 16MB 32 MB MB <--- 32 MB Network Software: Microsoft TCP stack PCTCP/Onnet Trumpet MacTCP Other: <--- Native Oberon for PC & Linux I have: No internet access Direct internet access Internet through PPP <--- Internet through Slip I don't use Oberon at the moment plan to use Oberon use some Oberon applications like text editing <--- have written small Oberon programs <--- constructed a user interface for my personal work with Oberon have manipulated gadgets by program have written an own gadget find the user interface a little weird like the user interface <--- have done a larger project in Oberon find the documentation lacking <--- compared to what ? would like to see more example programs would be interested in the source of the system <--- ? kernel am in love with Oberon ! My comments: The much hated mouse-cording, is a language in its own right. Perhaps analagous to 'stack-based' calculators (the original HP), much loved by the users who learned how to use them fluently - not me. Apparently the proper piano finguring is also irritating at first ? Chris Glur. ---- PS. is LNO (linux based n-o) X86 dependant, or cound it run on a non-X86 Linux ? I guess not.

1 0

Re: Trap in storing a FAT file.
by Peter Easthope 06 Jul '03

06 Jul '03

Chris, cg> I'm guessing that your machine is testing (which was not done before) that c.next = NIL occurs before the WHILE terminating condition is satisfied. cg> Compiler.Compile *\f Sure enough, the exection error is in this statement in OFSFATVolumes.AssignDirectoryEntry. WHILE (c.type # dcSentinel) & ((c.type # dcFree) OR (c.entry.dirInfo.num < direntry.dirInfo.num)) DO p := c; c := c.next END; Seems I need to make a comprehensive study of installable file systems and FAT. For now, this is the Kernel.Log after turning on Trace and Detail in the module (and recompiling and reloading of course). OFSFATVolumes should have written a raft of information which isn't there. Enough for now. Regards, Peter E. ETH Oberon / PC Native 05.01.2003 5 pages allocated, 4 pages reserved ATADisks 08.12.2000 by cp, pjm, prk IDE0..1: 14 000001F0 000003F6 reset ok IDE2..3: 15 00000170 00000376 Status 00000170 1 65535 15 255 FF FF FF 80 00 00 1000 IDE0, 258MB, 944*14*40, QUANTUM LPS270A OFSDiskVolumes: IDE0#2 00164378 System 0016B538 Objects 00171EC8 Display SVGA: ET4000 800x600 (+55 offscreen) 00188FB8 Input 0018E6F8 V24 001960F8 Fonts 00199278 Viewers 0019C518 Reals 0019F108 Texts 001A9678 Oberon 00052AD8 TextFrames 0005ACA8 MenuViewers 000686A8 ET 000776E8 FileSystem 00192128 In 0007A4B8 Out OFSDiskVolumes: IDE0#3 OFSDiskVolumes: IDE0#4 OFSFATVolumes: IDE0#1 mounted OFSFATFiles: C added 00309408 Diskettes 003187A8 SavePoints 0031CCC8 SaveScreen 00320FD8 Display3 00329C88 Pictures 0032DC88 Bitmaps 00344A48 Math 00346F08 RandomNumbers 0036ACE8 NetSystem 00371028 NetBase 003739C8 NetPorts 00375638 NetIP 0037A1E8 NetUDP 0037CA08 NetTCP 00383918 NetDNS 00387DB8 Strings 0038E368 Dates 003950C8 PPPMain 00398B28 PPPHDLC 0039AE58 PPPDebug 0039E038 PPPTools 003A0E38 PPPLCP 003A4978 PPPFSM 003A8698 PPPPAP 003AB5A8 PPPIPCP 003B36E8 Net3Com509 3Com509: 11 00000210 00:60:97:08:40:CC 10baseT TRAP -14 PC Native 05.01.2003 CS:=0000001B DS:=00000020 ES:=00000020 SS:=00000023 CR0=80040031 FPS=00000000 EIP=0002B243 ESI=00377748 EDI=003E3324 ESP=0011E280 CR2=00000000 SBT=0012001C EAX=00000000 EBX=00000000 ECX=003DAC4C EDX=00000003 CR3=0009D000 KFL=00003246 EBP=0011E298 FS:=00000000 GS:=00000000 ERR=00000004 CR4=00000000 TCK=0000C878 EFLAGS=00013293 (OCPAZS=010101 IT=10 D=0 IOPL=11 NT=0 AC,VM,RF=001) OFSFATVolumes PC=22443, OFSFATVolumes PC=24169, OFSFATFiles PC=2781, OFS PC=4688, Files PC=2024, ET PC=14016, ET PC=14672, ET PC=15089, Oberon PC=4860, TextFrames PC=12027, ... http://carnot.pathology.ubc.ca/peter.html

1 0