- Pharo-dev - lists.pharo.org

[Pharo-project] [ANN 1.2] pre-built core #12137

by Marcus Denker

https://gforge.inria.fr/frs/download.php/27474/PharoCore-1.2-12137.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Sept. 12, 2010

Re: [Pharo-project] Mark and space parity

by Gary Chambers

Generally, settings are stored in flash and changes should be permanent. Though we have had the odd Datalogic unit that tends to suffer from amnesia! Regards, Gary Sent from my iPad On 11 Sep 2010, at 19:25, "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> wrote: > Tony, I *almost* understand that, and greatly appreciate your reply. Compiling a new vm is getting to be routine, mostly because I find its diagnostic output to be far less than I typically want when sorting out a problem. Certainly the Windows vm goes out of its way to fail on valid settings and should be changed to allow parity values 3 and 4; the Linux vm might also benefit from relaxing its checks. > > The interesting part is that I don't need to send to the device, only read from it. If my notes are correct, it is 7S2. > > Gary, re programming by barcode, are you thinking that I might be able to get the scanner to use different settings? I wondered about that last night. There is a fairly extensive book full of barcodes that I believe are for changing the scanner's behavior. In your experience, are such changes stored in persistent store (flash, eprom, etc.), or are they transient such that they typically have to be restored each time the scanner loses power? If I can get it to use something friendly to the vm and stay that way, that might be a good solution. > > Bill > > > > ________________________________________ > From: Tony Garnock-Jones [tonyg(a)lshift.net] > Sent: Saturday, September 11, 2010 1:44 PM > To: The general-purpose Squeak developers list > Cc: Schwab,Wilhelm K; vm-dev(a)lists.squeakfoundation.org; Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [squeak-dev] Mark and space parity > > Hi Bill, > > Based on http://www.lothosoft.ch/thomas/libmip/markspaceparity.php, it looks > like you're set if you need 7S1. If you need 8S1, however, the options for > linux are > > - flip between 8N1 and 8E1 depending on the byte to send, or > - use the undocumented CMSPAR flag. > > Given that the SerialPort class in Squeak uses 0, 1, 2 for no, even and odd > parity respectively, and the sqUnixSerial.c driver doesn't support any other > kinds of parity specification (see the table parityTypeDecode), ruling out the > use of CMSPAR, your only option (aside from modifying the SerialPlugin or > writing your own) is to flip between 8N1 and 8E1 for each byte. Unfortunately > it doesn't look like there's a way to get at tcsetattr without also doing an > open, so there goes that idea as well. > > In summary: 7S1 ought to be OK (use 8N1 with a cleared 8th bit), but I suspect > that 8S1 is out of reach without changes to the SerialPlugin. > > Regards, > Tony > > > > On 11/09/2010 09:42, Schwab,Wilhelm K wrote: >> I ran across a device (barcode scanner) that uses space parity and dug into vm code to see if it was indeed going to be a problem. This is not a debate on whether or not the designers of the device could have chosen something else: clearly they should have. The question is whether our vms should be able to communicate with it, and they should where possible. >> >> It is not clear whether Linux even supports space parity, though there are hints that recent kernels do so. Windows certainly does support it. Have any of you made the required changes and had success with it? On which operating system(s)? >> >> Bill >> >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 12, 2010

Re: [Pharo-project] update to OCompletion

by Alexandre Bergel

> This is because when you have a line split into multiple lines, I want Enter to mean new line, not complete. This is particularly the case when you have pseudo-domain specific languages like in Glamour or Mondrian. A bit hard to get used to it, but I agree. > Nevertheless, I would say that once I pressed the down arrow, my focus is to the completion, and thus enter should mean selection of the completion. +1 Alexandre > > > > On 12 Sep 2010, at 01:30, Francisco Ortiz PeÃ±aloza wrote: > >> Hi, i'm trying the latest version cause i's tired of waiting for the >> switch to the longer list of suggestions. But i don't understand the >> following change >> >> -removed enter to insert a completion >> >> am i missing something? why do u ppl make this change? >> >> Cheers, >> Francisco Ortiz PeÃ±aloza >> >> On Wed, Aug 4, 2010 at 8:20 PM, Tim Mackinnon <tamackinnon(a)gmail.com> wrote: >>> I shall definitely give that a read - especially now i have an example to >>> think back on. >>> >>> By the way - these chapters that people keep writing, are a great help (the >>> monticello one certainly took away a huge load of frustrations I was having) >>> - so thanks to everyone that keeps chipping away at them! >>> >>> tim >>> >>> On 4 Aug 2010, at 18:44, Mariano Martinez Peck wrote: >>> >>>> I am glad I helped. You can also take a look to the Metacello draft we >>>> wrote for Pharo By Example 2. I attach it. >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Every thing has its own flow." > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 12, 2010

Re: [Pharo-project] update to OCompletion

by Tudor Girba

This is because when you have a line split into multiple lines, I want Enter to mean new line, not complete. This is particularly the case when you have pseudo-domain specific languages like in Glamour or Mondrian. Nevertheless, I would say that once I pressed the down arrow, my focus is to the completion, and thus enter should mean selection of the completion. Cheers, Doru On 12 Sep 2010, at 01:30, Francisco Ortiz PeÃ±aloza wrote: > Hi, i'm trying the latest version cause i's tired of waiting for the > switch to the longer list of suggestions. But i don't understand the > following change > > -removed enter to insert a completion > > am i missing something? why do u ppl make this change? > > Cheers, > Francisco Ortiz PeÃ±aloza > > On Wed, Aug 4, 2010 at 8:20 PM, Tim Mackinnon <tamackinnon(a)gmail.com> wrote: >> I shall definitely give that a read - especially now i have an example to >> think back on. >> >> By the way - these chapters that people keep writing, are a great help (the >> monticello one certainly took away a huge load of frustrations I was having) >> - so thanks to everyone that keeps chipping away at them! >> >> tim >> >> On 4 Aug 2010, at 18:44, Mariano Martinez Peck wrote: >> >>> I am glad I helped. You can also take a look to the Metacello draft we >>> wrote for Pharo By Example 2. I attach it. >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Every thing has its own flow."

Sept. 12, 2010

[Pharo-project] Squeak VM on iPad/IPhone gets open/GL rendering

by John M McIntosh

On friday night I created an open/GL renderer to work with Squeak screen updates on the iPhone/iPad. Unfortunately it runs slows than the tiled Core Animation render that I had work out earlier in the year with help from the Apple graphics engineers. So if anyone has a fair amount of knowledge about Open/GL ES maybe they could contact me and we'll see if we can improve things? -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Sept. 11, 2010

Re: [Pharo-project] update to OCompletion

by Francisco Ortiz PeÃ±aloza

Hi, i'm trying the latest version cause i's tired of waiting for the switch to the longer list of suggestions. But i don't understand the following change -removed enter to insert a completion am i missing something? why do u ppl make this change? Cheers, Francisco Ortiz PeÃ±aloza On Wed, Aug 4, 2010 at 8:20 PM, Tim Mackinnon <tamackinnon(a)gmail.com> wrote: > I shall definitely give that a read - especially now i have an example to > think back on. > > By the way - these chapters that people keep writing, are a great help (the > monticello one certainly took away a huge load of frustrations I was having) > - so thanks to everyone that keeps chipping away at them! > > tim > > On 4 Aug 2010, at 18:44, Mariano Martinez Peck wrote: > >> I am glad I helped. You can also take a look to the Metacello draft we >> wrote for Pharo By Example 2. I attach it. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 11, 2010

[Pharo-project] Issue 2479

by Francisco Ortiz PeÃ±aloza

Hi, New SmalltalkEditor doesnt know how to handle ESC key pressed event. http://code.google.com/p/pharo/issues/detail?id=2947 Cheers, Francisco PD: Due to connections problems i submited three times the same issue, please someone fix it!

Sept. 11, 2010

Re: [Pharo-project] WebClient License Update

by Andreas Raab

On 9/9/2010 1:15 AM, Henrik Johansen wrote: > > On Sep 9, 2010, at 4:27 50AM, Andreas Raab wrote: > >> Phillipe wrote: >>> Did you change your position towards #squeakToUtf8 and string >>> concatenation (I didn't follow the entire previous thread)? >> >> Implicitly yes, but let's discuss this. You're saying you want WebClient "without overrides" but is this really what you mean? The only reason these methods are marked overrides is so that they don't kill your system if the methods themselves get added to the system at some point. For example, Grease currently adds extension methods for Collection>>sorted but these methods are already in Squeak and while nothing harmful happens if you load Grease, unloading it will destroy several methods. As a consequence it is vastly advantageous to mark methods as overrides if they have even the slightest possibility to conflict (but of course if you'd rather have them straightforward extensions, I have no problems with that). >> >> As for integrating the changes itself, I think that we're talking two very different issues here. I suspect that the only objection to #squeakToUtf8 and #utf8ToSqueak is that they have "Squeak" in their name. I don't think you'd have any objection if they would've been called #utf8Encoded and #utf8Decoded. Which, honestly, is a childish attitude from my point of view. > > Yeesh. > I can only speak for myself, but my objection to the methods is more that I don't think knowing how to change its contents to a specific encoding should be the responsibility of the String class. > Yes, there are plenty of other comparable delegations of responsibility, but in this case it is easily avoided. > Sure though, it's a bit faster in some cases than the alternatives using convertToWithConverter:, or convertToEncoding: (at least with a symbol -> converter cache added), > but with the general improvements to UTF8TextConverter the speedup is no longer measured in the orders of magnitudes, where it might feel worth it (to me). Which isn't really the argument. The utf8 encoding and decoding methods are by far the most commonly used conversion methods. They are similar to methods such as #zipped/#unzipped, or #base64Encoded/#base64Decoded. I actually have some code that literally uses: data := aString squeakToUtf8 zipped base64Encoded. Compare that with the (exactly) equivalent version that doesn't have the utility methods: (Base64MimeConverter mimeEncode: (((GZipWriteStream on: (RWBinaryOrTextStream on: String new)) nextPutAll: (aString convertToWithConverter: UTF8TextConverter new); close; encodedStream) contents) readStream) contents Thus, the basic claim here is that it's worthwhile to have shorthand methods for conversion to/from utf8 because it's so prevalent. As for why it's called squeakToUtf8 and utf8ToSqueak, that's simply because there's a family of conversion methods in String which use the squeakToXXX/xxxToSqueak pattern (remnants of which you can still find in Pharo). These methods got first introduced around Squeak 3.8 to deal with various issues during m17n integration and have been in Squeak ever since. >> Put differently, the change adds nothing but robustness to the system. There is really no data to back up the FUD about all the changes that "may" go wrong, but from my experience there is ample evidence to show that logging and error handling involving string concatenation is highly susceptible to this kind of problem and generally not very well tested and difficult to QA. And the major use of string concatenation is right in these areas. > > While I see some value in your arguments, in addition to Pharo, at least the VW, GST and ST-X dialects, plus the ANSI standard, do not allow it. > IE, if you want to write your code the least bit portable, you include the ugly as/printString sends. Unless you convince people to change things. Would make a fine addition to Grease, too :-) Cheers, - Andreas

Sept. 11, 2010

Re: [Pharo-project] Mark and space parity

by Schwab,Wilhelm K

Tony, I *almost* understand that, and greatly appreciate your reply. Compiling a new vm is getting to be routine, mostly because I find its diagnostic output to be far less than I typically want when sorting out a problem. Certainly the Windows vm goes out of its way to fail on valid settings and should be changed to allow parity values 3 and 4; the Linux vm might also benefit from relaxing its checks. The interesting part is that I don't need to send to the device, only read from it. If my notes are correct, it is 7S2. Gary, re programming by barcode, are you thinking that I might be able to get the scanner to use different settings? I wondered about that last night. There is a fairly extensive book full of barcodes that I believe are for changing the scanner's behavior. In your experience, are such changes stored in persistent store (flash, eprom, etc.), or are they transient such that they typically have to be restored each time the scanner loses power? If I can get it to use something friendly to the vm and stay that way, that might be a good solution. Bill ________________________________________ From: Tony Garnock-Jones [tonyg(a)lshift.net] Sent: Saturday, September 11, 2010 1:44 PM To: The general-purpose Squeak developers list Cc: Schwab,Wilhelm K; vm-dev(a)lists.squeakfoundation.org; Pharo-project(a)lists.gforge.inria.fr Subject: Re: [squeak-dev] Mark and space parity Hi Bill, Based on http://www.lothosoft.ch/thomas/libmip/markspaceparity.php, it looks like you're set if you need 7S1. If you need 8S1, however, the options for linux are - flip between 8N1 and 8E1 depending on the byte to send, or - use the undocumented CMSPAR flag. Given that the SerialPort class in Squeak uses 0, 1, 2 for no, even and odd parity respectively, and the sqUnixSerial.c driver doesn't support any other kinds of parity specification (see the table parityTypeDecode), ruling out the use of CMSPAR, your only option (aside from modifying the SerialPlugin or writing your own) is to flip between 8N1 and 8E1 for each byte. Unfortunately it doesn't look like there's a way to get at tcsetattr without also doing an open, so there goes that idea as well. In summary: 7S1 ought to be OK (use 8N1 with a cleared 8th bit), but I suspect that 8S1 is out of reach without changes to the SerialPlugin. Regards, Tony On 11/09/2010 09:42, Schwab,Wilhelm K wrote: > I ran across a device (barcode scanner) that uses space parity and dug into vm code to see if it was indeed going to be a problem. This is not a debate on whether or not the designers of the device could have chosen something else: clearly they should have. The question is whether our vms should be able to communicate with it, and they should where possible. > > It is not clear whether Linux even supports space parity, though there are hints that recent kernels do so. Windows certainly does support it. Have any of you made the required changes and had success with it? On which operating system(s)? > > Bill > > >

Sept. 11, 2010

Re: [Pharo-project] WebClient License Update

by Andreas Raab

On 9/9/2010 3:34 AM, StÃ©phane Ducasse wrote: >> For string concatenation on the other hand, we're basically talking about dispersing a whole load of FUD about all the things that "may" go wrong. Fact is, nothing actually *does* go wrong with the change, but the change does fix situations that are *very* difficult to handle otherwise. One of the unfortunate realities of string concatenation is that it's very often used around error messages and logging, often in corner cases that aren't well tested, like: >> >> <some impossible condition> ifTrue:[ >> self log: 'Found impossible condition: ', foo. >> ]. > > I do not buy this argument. We should fix the code and not break the libraries. Yes, that is the usual FUD. Can you clarify how that change breaks any libraries, where and when exactly? Because it doesn't. > Your argument is bogus. Which one? I made about five different arguments from that this change doesn't break anything, over it preserving the type semantics, that string concatenation often occurs in less tested code, that it is error-prone for no good reason, up until the efficiency argument. Or is it simply "I don't like this guy so matter what he says I will not listen"? > We do not want such kind of extensions that opens the door to really sloppy code. And that would be sloppy code because ... ? It's more efficient to write it that way? Is that your measure of sloppyness? If not how do you distinguish "sloppy" code from other perfectly well accepted patterns like the type coercions happening in arithmetic? You *could* write "4 asFloat + 3.0" instead of "4 + 3.0" you know. > Then we should avoid overrides as much as possible. I wholeheartedly agree but did you actually follow the Grease discussion? The problem of not being able to remove methods after they have been added to the base is quite real. The only way to address this problem currently is by using overrides. Cheers, - Andreas

Sept. 11, 2010