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

{Oberon] Linux port of Bluebottle
by paul provoost 25 Aug '06

25 Aug '06

Hi all, I am also interested in a Linux port of Bluebottle. Anyone else? Who could do such a port? P. Provoost. The Netherlands. _________________________________________________________________ MSN Search, for accurate results! http://search.msn.nl

4 5

Re: [Oberon] Re. pe.URI.Mod
by shark＠gulfnet.sd64.bc.ca 28 Jul '06

28 Jul '06

Chris, cg> Watson.ShowDef URI.Mod == nill Open pe.URI.Mod and * mark it. Open the Watson.Panel. Click the Show Def * button. The definitions will be dsplayed. cg> System.Directory UR*Obj == nill System.Directory *UR* ~ cg> URI seems to suggest use of DNS ? It is just a reimplementation of ESC and UnESC. No direct involvement of DNS. Regards, ... Peter Desktops.OpenDoc http://carnot.pathology.ubc.ca/

1 0

Re. pe.URI.Mod
by easlab＠absamail.co.za 28 Jul '06

28 Jul '06

Peter wrote: > A revised pe.URI.Mod is now available. > Desktops.OpenDoc http://carnot.pathology.ubc.ca/oberon.html > Search down for URI. > > Most of the changes including at least one serious bug > were reported by Jan Verhoeven. Thanks Jan. > > As time is available I'll incorporate this into NetSystem > and HyperDocs. > > Bug reports and further suggestions for improvements > remain welcome. Watson.ShowDef URI.Mod == nill System.Directory UR*Obj == nill It's natural/easy, when one has been working extensively on a project, to discount the the lowest, most trivial aspects, like a description of what it is. That's why I think every 'contribution directory' should have a ReadMe file. In order to capture these mind-dumbing but essential details, [which IMO are equivalent to syntax] I believe in form-based assistance. Like N-O's *.Tool acts as a prompt for the trivial details. Debian eg. seems to have a good set of guidelines for the human collaboration protocol. Once a project has been running for years with multiple collaborators. The 'organisation' should have evolved solutions, which are written down, for the repeating problems. It seems that ETH source files eg. have the 'Copyright, portable or not, date' fields'. I believe that other fields could be added. Formally - like a syntax. Hence forms based. Ie. think/design once and use multiple times ? ------------ URI seems to suggest use of DNS ? I'm not aware of any DNS problems with N-O usage. Is this perhaps not for N-O ? Thanks, == Chris Glur.

1 0

pe.URI.Mod
by shark＠gulfnet.sd64.bc.ca 27 Jul '06

27 Jul '06

A revised pe.URI.Mod is now available. Desktops.OpenDoc http://carnot.pathology.ubc.ca/oberon.html Search down for URI. Most of the changes including at least one serious bug were reported by Jan Verhoeven. Thanks Jan. As time is available I'll incorporate this into NetSystem and HyperDocs. Bug reports and further suggestions for improvements remain welcome. Thanks, ... Peter Desktops.OpenDoc http://carnot.pathology.ubc.ca/

1 0

Re. Mi-Fi Mp3 *.wav files not playable on OTHER players ?
by easlab＠absamail.co.za 18 Jul '06

18 Jul '06

Hendrik Potgieter, 18 July 2006 Please forward this to Bernard Blom. Bernard Blom wrote:- > I just had a look at this question and I thing the answer would be to > simply change the file extension to *.MP3. I had it both as .mp3 and > ..wma and they both played 100%. > No. I examined the header bytes with a hex-viewer. And as expected these files are not *.mp3. They look like *.wav files, as the player/recorder has named them to be. Of course they play properly on the Kallliba player. But they fail on other *.wav players which I have. I don't have a *.wma available, so I can't yet see what the headers look like. NB. if the Kalliba recorded speech files can't be palyed on other players, then our archives are worthless, and can't be transmitted to other parties. > If you have any other questions, please contact me. Thanks, == Chris Glur 450-2105 > Regards > Bernard Blom

1 0

Re. Mi-Fi Mp3 *.wav files not playable on OTHER players ?
by easlab＠absamail.co.za 18 Jul '06

18 Jul '06

Hendrik Potgieter, 18 July 2006 Please forward this to Bernard Blom. Bernard Blom wrote:- > I just had a look at this question and I thing the answer would be to > simply change the file extension to *.MP3. I had it both as .mp3 and > ..wma and they both played 100%. > No. I examined the header bytes with a hex-viewer. And as expected these files are not *.mp3. They look like *.wav files, as the player/recorder has named them to be. Of course they play properly on the Kallliba player. But they fail on other *.wav players which I have. I don't have a *.wma available, so I can't yet see what the headers look like. NB. if the Kalliba recirded speech files can't be palyed on other players, then our archives are worthless, and can't be transmitted to other parties. > If you have any other questions, please contact me. Thanks, == Chris Glur 450-2105 > Regards > Bernard Blom

1 0

Re. Message system fault
by easlab＠absamail.co.za 18 Jul '06

18 Jul '06

Sometimes by making more effort to describe the problem to an outsider, we gain extra insight, or even the solution, ourselves ? Dan Parnete wrote: > On 10.05.06 I have posted a message about "Message queue and > Pointer". I talked about a big amount of messages on the queue (due to > the number of components moved in the display space) that caused the > Pointer events to be wrong interpreted. > > This time I will expose a similar wrong PointerDown event > interpretation of a scrollbar, due to the time spent to render images on > a tabular form. Yes, it is natural that subtle bugs don't get fixed provided users can work-around or avoid them. But it's more economical to muster the critical-mass to fix them early than allow them to linger like the N-O ppp problem. > To observe this you need to download the BBwClient from > ftp://194.243.0.14 and install it. At the login window, first press > ctrl-o to open the Kernel Log, then write: > What is a "pointer" in the context of a message queue ? It's easy to forget that this mail-list has forked to cater for several [hopefully still related] systems. My N-O & Linux-oberon don't react to ctrl-o, but it is possible to display the Kernel Log. > Application: 85.18.123.96/Dan > Database: DanDb > User: public > Password: user > At the first time a modules upgrade will be done, and then exits. You > have to reenter. Then go to Clienti in the menu bar and select the first > record in the record's list (Ala Data System srl). The interested form > is the bottom one. The first two records have an image attached, and we > will use the vertical scrollbar for the demonstration. If you click on > the arrowDown button, if you are speed enough, you will obtain the > desired effect: one row scroll down. Yes, I remember these 'time/speed related effects' while trying to debug N-O/ppp. OTOH serial-lockup re. ppp has many reports on the net, dating back to 1989. Can you produce 'the fault' by other than your software ? > If not, if the mouse will transmit > two (or more) repeated clicks, an unpredictable number of scroll down > will be done (see "ScrollbarChanged pos = x" in the Log), much more then > the real number of clicks transmitted. The first event will start an > image download from the server. During this time the arrowButton rest > pressed, even if you don't thatch anymore the mouse, and continue to > register PointerDown events. As soon as the records with image > disappear, the arrowButton is released. > More interesting is the consequence if you press the arrowUp button to > scroll up. Due to the continuous downloading, the scrolling could > continue for a while. > I'm reminded of the unsolved ppp > dial > ser-port > V24 which also potentially relates to a [serial] mouse. Or are you using eg a usb-mouse. My theory is that many of these problems are never solved. The industry just finds work-arounds, and bluffs themselves that they understood it and solved it. > Observations: > 1. Independent of the reason, the message system has a fault. It is not > admissible to register on the queue more Pointer events then those > driven by the user. > 2. To limit the scrolling erroneous effects, the scrollbar must: > - call DecPos only if pos > 0 > - call IncPos only if pos < max > Applying this restrictions I have eliminated the undesired effect on the > WeelMove. Perhaps if you 'translate' your report to more general/abstract [independant of your application] terms it would better advance the problem towards a solution ? == Chris Glur.

1 0

Re: [Oberon] Re. forwarding an emessage
by shark＠gulfnet.sd64.bc.ca 13 Jul '06

13 Jul '06

Chris, cg> If you already can send an attachment, then you could simply decode the received attachment to ascii and send THAT as a new attatchment. Ie. make the attachment an 'original' and re-attach it. That works but is too inefficient. Cutting and pasting from MailMessages worked for one case yesterday. Will stick to that until a better idea surfaces. Thanks, ... Peter E. Desktops.OpenDoc http://carnot.pathology.ubc.ca/

1 0

Re. forwarding an emessage
by easlab＠absamail.co.za 13 Jul '06

13 Jul '06

shark(a)gulfnet.sd64.bc.ca wrote: > Can anyone recommend an efficient way of > forwarding an emessage which has one or > more attachments? > > If I readdress the incoming message in > its viewer, critical information from the > header will be lost. Any clever methods > other than copying from MailMessages to > the new message viewer? BTW Hex.Open ^ is good to see the real bytes. I've never posted an attatchment and I get annoyed when I receive them without good reason. I use the lowest-tech: TextMail.Send to send and TextMail.Directory to receive. But I have seen mention of facilities to send attatchments with N-O's 'mail-panel[s]'. If the attachment which you receive [via the mail-panel] goes to a *.Temp, like eg. gif.Temp ...etc. does, then provided you don't load it to a frame and re-save it, it doesn't mess the 'header'. Ie. the original binary is retained. For my primitive method: via TextMail.* , I'd just paste my text above the original attachment [with it's header]. eg. original receipt has: 1. email header 2. text from sender 3. standard 'header' of base64 4. actual lines of encoded base64 5. tail 'marker ' of encoded base64 I'd just replace 1 & 2. And self-send as a test. If you already can send an attachment, then you could simply decode the received attachment to ascii and send THAT as a new attatchment. Ie. make the attachment an 'original' and re-attach it. If your've got many to do, best write an "ET.Do script". == Chris Glur.

1 0

forwarding an emessage
by shark＠gulfnet.sd64.bc.ca 12 Jul '06

12 Jul '06

Hello, Can anyone recommend an efficient way of forwarding an emessage which has one or more attachments? If I readdress the incoming message in its viewer, critical information from the header will be lost. Any clever methods other than copying from MailMessages to the new message viewer? Thanks, ... Peter E. Desktops.OpenDoc http://carnot.pathology.ubc.ca/

1 0