July 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Working with urls that contain non latin characters

by Herbert VojÄÃk

Offray Vladimir Luna CÃ¡rdenas wrote on 27. 7. 2018 12:39: > Hi, > > I was ready to show a friend the Pharo web capabilities with the > classical "myString asUrl retrieveContents", but the friend gave me a > url that contains non Latin characters[1] and then I got an > ZnInvalidUTF8 error. > > [1] > http://www.bidchance.com/freesearch.do?&filetype=&channel=&currentpage=1&se… > > How can I process web addresses in Pharo that contain non latin > characters like the one in [1]? Maybe you can make it into additional test case(s) in Zinc and upload them so authors (or anyone else willing to) can take on from that point and fix them. I also faintly remember Zinc having some problems when I worked with it and the need to devise workarounds around asUrl use. > Thanks, > > Offray

July 27, 2018

Working with urls that contain non latin characters

by Offray Vladimir Luna CÃ¡rdenas

Hi, I was ready to show a friend the Pharo web capabilities with the classical "myString asUrl retrieveContents", but the friend gave me a url that contains non Latin characters[1] and then I got an ZnInvalidUTF8 error. [1] http://www.bidchance.com/freesearch.do?&filetype=&channel=&currentpage=1&se… How can I process web addresses in Pharo that contain non latin characters like the one in [1]? Thanks, Offray

July 27, 2018

Re: [Pharo-users] SpecGenerator

by Stephan Eggermont

john pfersich <jpfersich(a)gmail.com> wrote: > I have a question about SpecGenerator. The video introducing SpecGenerator > about 2 years ago says you start it with: > MEApplicationList open. > > There's no open method in version 15 that I loaded from SmalltalkHub. > > How do you start the app? > > See the MEApplicationList class comment

July 26, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by Norbert Hartl

> Am 26.07.2018 um 17:59 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > Richard, > > I am only engaging in a discussion with you in order to explain what we did and why. The changes that we did were years in the making and are now being pushed into the system. The discussions happened long ago, we are not going to revert them. > > Of course you are entitled to have your own opinion and disagree. > > I do not know what 'your system' is that you are referring to. > > Pharo has a particular philosophy that includes a complex relationship with the concepts of Smalltalk and especially ANSI Smalltalk. In one sentence, we want to have to liberty to make (breaking) changes and don't want to be stuck in the past. At the same time we want our user base to be able to follow by adapting their code. > +1 Norbert > Regards, > > Sven > >> On 26 Jul 2018, at 17:06, Richard O'Keefe <raoknz(a)gmail.com> wrote: >> >> Yes there was no mention of BOMs, but there *was* mention of >> #position, and the presence or absence of byte order marks >> makes a difference. >> >> As for mailing list discussions over a year, that is not the >> kind of single coherent source I was hoping for. >> >> As someone *using* the system classes, I don't give a damn >> how big they are. What I care about is the complexity of >> *my* code, and it looks as though the new interface will >> make my code bigger, more error-prone, and less portable. >> As for the "big hairy classes" sneer, the file stream >> classes put together in my system are about the same size >> as the Dictionary class proper. >> >> I don't "want to make users set environment variables". >> What I was suggesting was that if a user does go to the >> trouble of setting relevant environment variables, the >> system should have the decency to pay attention to them. >> >> handling /dev/std... is pretty trivial in UNIX; in Windows >> nothing about stdin is easy (XP, Vista, 7, 8, and 10 differ >> amongst themselves in several annoying ways). >> >> I can make no sense of the comment that interpreting #'text' >> as #utf8 (always, as a design choice) or as whatever the >> user chose for $LC_CTYPE (always, as a design choice) is >> "not very Smalltalk like". Both design choices are fully >> consistent with the standard -- to the limited extent that >> UTF8 processing *can* be consistent with the standard. >> >> >> On 24 July 2018 at 05:40, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 23 Jul 2018, at 18:52, Richard O'Keefe <raoknz(a)gmail.com> wrote: >>> >>> Oh, I think a clarification is needed when talking about UTF-8. >> >> Why ? >> >>> To the best of my knowledge you don't need a Byte-Order-Mark at >>> the beginning of a UTF-8 stream because there is no byte order >>> issue to result, >> >> Nothing was said about BOMs. >> >>> but apparently many Windows programs like to add one. >> >> Apparently yes. >> >>> Does/will Pharo add one when writing a UTF-8 file? >> >> No >> >>> Does/will it skip one when reading a UTF-8 file? >> >> Yes >> >>> I find the new approach produces unattractive code. I can do >>> all of the examples simply in a system that >>> (a) implements the ANSI Smalltalk FileStream class methods >> >> Given a FileReference object of some kind you ask for the streams you need. Seems pretty OO if you ask me. >> >> Do you prefer a global class side factory facade ? >> >> Both approaches are not exclusive per se, we just want a clear break/difference (because the resulting streams are not 100% the same). >> >>> (b) supports '/dev/stdin' and '/dev/stdout' as file names >> >> Maybe, with special casing. I like 'Stdio stdout' better as it is more cross platform. >> >>> (c) interprets the external type #'text' either as #'utf8' LC_CTYPE >> >> Maybe, but that is not very Smalltalk like is it ? You want users to set environment variables ? Anyway this is less important point as UTF-8 is (should be) the general default. >> >>> What document should I read to get a mental model of the new >>> system and understand its rationale? >> >> ML discussions over the year, I guess. >> >> We are generally against big hairy complex classes and prefer simpler ones. >> >> >> > >

July 26, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by Sven Van Caekenberghe

Richard, I am only engaging in a discussion with you in order to explain what we did and why. The changes that we did were years in the making and are now being pushed into the system. The discussions happened long ago, we are not going to revert them. Of course you are entitled to have your own opinion and disagree. I do not know what 'your system' is that you are referring to. Pharo has a particular philosophy that includes a complex relationship with the concepts of Smalltalk and especially ANSI Smalltalk. In one sentence, we want to have to liberty to make (breaking) changes and don't want to be stuck in the past. At the same time we want our user base to be able to follow by adapting their code. Regards, Sven > On 26 Jul 2018, at 17:06, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > Yes there was no mention of BOMs, but there *was* mention of > #position, and the presence or absence of byte order marks > makes a difference. > > As for mailing list discussions over a year, that is not the > kind of single coherent source I was hoping for. > > As someone *using* the system classes, I don't give a damn > how big they are. What I care about is the complexity of > *my* code, and it looks as though the new interface will > make my code bigger, more error-prone, and less portable. > As for the "big hairy classes" sneer, the file stream > classes put together in my system are about the same size > as the Dictionary class proper. > > I don't "want to make users set environment variables". > What I was suggesting was that if a user does go to the > trouble of setting relevant environment variables, the > system should have the decency to pay attention to them. > > handling /dev/std... is pretty trivial in UNIX; in Windows > nothing about stdin is easy (XP, Vista, 7, 8, and 10 differ > amongst themselves in several annoying ways). > > I can make no sense of the comment that interpreting #'text' > as #utf8 (always, as a design choice) or as whatever the > user chose for $LC_CTYPE (always, as a design choice) is > "not very Smalltalk like". Both design choices are fully > consistent with the standard -- to the limited extent that > UTF8 processing *can* be consistent with the standard. > > > On 24 July 2018 at 05:40, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 23 Jul 2018, at 18:52, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > > > Oh, I think a clarification is needed when talking about UTF-8. > > Why ? > > > To the best of my knowledge you don't need a Byte-Order-Mark at > > the beginning of a UTF-8 stream because there is no byte order > > issue to result, > > Nothing was said about BOMs. > > > but apparently many Windows programs like to add one. > > Apparently yes. > > > Does/will Pharo add one when writing a UTF-8 file? > > No > > > Does/will it skip one when reading a UTF-8 file? > > Yes > > > I find the new approach produces unattractive code. I can do > > all of the examples simply in a system that > > (a) implements the ANSI Smalltalk FileStream class methods > > Given a FileReference object of some kind you ask for the streams you need. Seems pretty OO if you ask me. > > Do you prefer a global class side factory facade ? > > Both approaches are not exclusive per se, we just want a clear break/difference (because the resulting streams are not 100% the same). > > > (b) supports '/dev/stdin' and '/dev/stdout' as file names > > Maybe, with special casing. I like 'Stdio stdout' better as it is more cross platform. > > > (c) interprets the external type #'text' either as #'utf8' LC_CTYPE > > Maybe, but that is not very Smalltalk like is it ? You want users to set environment variables ? Anyway this is less important point as UTF-8 is (should be) the general default. > > > What document should I read to get a mental model of the new > > system and understand its rationale? > > ML discussions over the year, I guess. > > We are generally against big hairy complex classes and prefer simpler ones. > > >

July 26, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by Richard O'Keefe

Yes there was no mention of BOMs, but there *was* mention of #position, and the presence or absence of byte order marks makes a difference. As for mailing list discussions over a year, that is not the kind of single coherent source I was hoping for. As someone *using* the system classes, I don't give a damn how big they are. What I care about is the complexity of *my* code, and it looks as though the new interface will make my code bigger, more error-prone, and less portable. As for the "big hairy classes" sneer, the file stream classes put together in my system are about the same size as the Dictionary class proper. I don't "want to make users set environment variables". What I was suggesting was that if a user does go to the trouble of setting relevant environment variables, the system should have the decency to pay attention to them. handling /dev/std... is pretty trivial in UNIX; in Windows nothing about stdin is easy (XP, Vista, 7, 8, and 10 differ amongst themselves in several annoying ways). I can make no sense of the comment that interpreting #'text' as #utf8 (always, as a design choice) or as whatever the user chose for $LC_CTYPE (always, as a design choice) is "not very Smalltalk like". Both design choices are fully consistent with the standard -- to the limited extent that UTF8 processing *can* be consistent with the standard. On 24 July 2018 at 05:40, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 23 Jul 2018, at 18:52, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > > > Oh, I think a clarification is needed when talking about UTF-8. > > Why ? > > > To the best of my knowledge you don't need a Byte-Order-Mark at > > the beginning of a UTF-8 stream because there is no byte order > > issue to result, > > Nothing was said about BOMs. > > > but apparently many Windows programs like to add one. > > Apparently yes. > > > Does/will Pharo add one when writing a UTF-8 file? > > No > > > Does/will it skip one when reading a UTF-8 file? > > Yes > > > I find the new approach produces unattractive code. I can do > > all of the examples simply in a system that > > (a) implements the ANSI Smalltalk FileStream class methods > > Given a FileReference object of some kind you ask for the streams you > need. Seems pretty OO if you ask me. > > Do you prefer a global class side factory facade ? > > Both approaches are not exclusive per se, we just want a clear > break/difference (because the resulting streams are not 100% the same). > > > (b) supports '/dev/stdin' and '/dev/stdout' as file names > > Maybe, with special casing. I like 'Stdio stdout' better as it is more > cross platform. > > > (c) interprets the external type #'text' either as #'utf8' LC_CTYPE > > Maybe, but that is not very Smalltalk like is it ? You want users to set > environment variables ? Anyway this is less important point as UTF-8 is > (should be) the general default. > > > What document should I read to get a mental model of the new > > system and understand its rationale? > > ML discussions over the year, I guess. > > We are generally against big hairy complex classes and prefer simpler ones. > > >

July 26, 2018

Re: [Pharo-users] Pharo7, consistent image freeze/deadlock on snapshotAndQuit

by Ben Coman

I don't have a total answer, but can confirm the problem and help characterize it. First, great test-snippet. Really nice and concise. On Windows it indeed freezes my Pharo 7 image when saving the image. It doesn't freeze Pharo 6. It doesn't freeze if the test-processes are not terminated. It doesn't freeze if the shutdown code runs at a lower priority that the test-processes. i.e. it works with these added lines... shutDown: quitting "+" |restorePriority| "+" restorePriority := Processor activeProcess priority. "+" Processor activeProcess priority: 15. Process1 ifNotNil:[ Process1 terminate ]. Process2 ifNotNil: [Process2 terminate ]. "+" Processor activeProcess priority: restorePriority. Process1 := Process2 := nil Does that help someone else identify the relevant changes between Pharo 6 & 7 to explain the behaviour in more depth. cheers -ben On 26 July 2018 at 00:46, Johan Brichau <johan(a)inceptive.be> wrote: > Hi, > > I ran into a freeze issue when trying to save and/or quit an image after loading Seaside3 and Zinc (not an infrequent combination :) > > The cause seems to be that terminating processes in a `shutDown` handler (called on image shutdown / snapshot) leads to a deadlock (somewhere). > Both Comet and Zinc will send #terminate to a process when an image is quit or saved. If I disable one of those, the deadlock does not occur. > > I managed to reconstruct the issue with a simple example, attached. > > The attached Freeze class creates two processes (that loop with a Delay>>wait inside) in the `startUp` method (on image start). > These processes are terminated by the shutdown method (called on image quit/save). > However, when you try to quit and/or save the image, you will experience an image freeze. > > Iâm not familiar with the process scheduler, or anything else in this contextâ¦ so help would be appreciated while I try to dive further into it :) > > To reproduce: just file in the attached file in a Pharo7 image and try to quit. > For reference, System Reporter output for my configuration. > > Any ideas? > > Cheers > Johan > > > > > Image > ----- > /Users/jbrichau/Pharo/images/Pharo 7.0 - 64bit (development version)/Pharo 7.0 - 64bit (development version).image > Pharo7.0alpha > Build information: Pharo-7.0+alpha.build.1131.sha.a46bfaef44ba209888c92fa0e3bd3a5e04a38c5d (64 Bit) > Unnamed > > Virtual Machine > --------------- > /Users/jbrichau/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo > CoInterpreter VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 > StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 > VM: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jun 28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > > Mac OS X built on Jun 28 2018 13:07:33 UTC Compiler: 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31) > VMMaker versionString VM: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jun 28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > CoInterpreter VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 > StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 > >

July 26, 2018

Re: [Pharo-users] Status of Caffeine

by Siemen Baader

Hi again, I played a bit with the online demo. Do you have implemented a basic file browser with DOM (not canvas) UI? But it is not compatible at the Morphic level, right? So it is not a DOM element based backend that existing Morphic applications could use..? Also, what happens when you have an exception in code in a DOM callback like xhr completed or a click event? Does it pop up a real Squeak debugger and allows coding in the debugger like real smalltalk? Cheers, Siemen Sent from my iPhone > On 20 Jul 2018, at 11.27, Siemen Baader <siemenbaader(a)gmail.com> wrote: > > Ok, Thanks! > > :) > Siemen > > Sent from my iPhone > >> On 20 Jul 2018, at 10.08, Craig Latta <craig(a)blackpagedigital.com> wrote: >> >> >>> What about the UI lag and the occasional spinner that blocks the UI, >>> is this related to the debugging protocol (I see that the IDEs are >>> loaded in iframes) that will go away when run from local, or is this >>> something that can be optimized away? >> >> That's just the speed of Morphic. The VM is set up to display the >> spinner whenever anything takes more than a certain amount of time (one >> alternative is to just turn it off :). While Morphic in SqueakJS has >> gotten a lot faster since the first release, just because JavaScript >> engines have gotten faster, I was still motivated to explore >> alternatives. That's why I experimented with animated HTML wireframes, >> morphic.js from Snap, and using a separate HMTL5 canvas for each morph. >> >> All three of these approaches are much faster than traditional >> Morphic. However, the traditional Morphic UI has the appeal that it's >> pixel-portable between the Web and native apps. >> >> >> thanks again, >> >> -C >> >> -- >> Craig Latta >> Black Page Digital >> Amsterdam :: San Francisco >> craig(a)blackpagedigital.com >> +31 6 2757 7177 (SMS ok) >> + 1 415 287 3547 (no SMS) >>

July 26, 2018

SpecGenerator

by john pfersich

I have a question about SpecGenerator. The video introducing SpecGenerator about 2 years ago says you start it with: MEApplicationList open. There's no open method in version 15 that I loaded from SmalltalkHub. How do you start the app?

July 26, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by David T. Lewis

On Wed, Jul 25, 2018 at 02:20:30PM +0200, Damien Pollet wrote: > On Wed, 25 Jul 2018 at 13:48, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 25 Jul 2018, at 13:39, Damien Pollet <damien.pollet+pharo(a)gmail.com> > > wrote: > > > Related issue: command line arguments come from VM system attributes as > > ByteStrings??? and thus interpreted as iso-8859-1, which is incorrect in most > > cases nowadays, even though it seems to work as long as you only use ASCII. > > Decoding them is easy enough, but it requires two copies (asByteString > > utf8Decoded) > > > > Yes this is a really big issue. Anything coming in as command line arg or > > environment variable (or clipboard) is in a basically unknown OS determined > > encoding. I would assume/hope the UTF-8 is the sensible default today, but > > apparently not. And it is hard to find a cross platform solution. > > > > My point here was that it would make more sense for those to be passed into > the image as ByteArrays, revealing the fact that their encoding is unknown. > Currently the bytes are correct, but since they've been shoved into > ByteStrings by the VM, the characters will be wrong unless your system > happens to be using Latin 1. That sounds right to me. Having said that, there should be no need to change the VM interface to do this. A ByteString is by definition an array of 8 bit wide characters, and conversion between ByteString and ByteArray is trivial. Any necessary changes can be done without touching the VM. Dave > > I suppose we can either have a setting for decoding (since it's pretty much > arbitrary), or heuristics like checking LC_CTYPE or whatever. Pablo > mentioned the Locale class, but it doesn't seem to detect anything correct > from the environment.

July 26, 2018