May 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Write accentuate characters in file

by Damien Cassou

On Mon, May 16, 2011 at 5:01 PM, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > FileStream newFileNamed: 'test.txt' do: [ :stream | > Â Â Â stream converter: MacRomanTextConverter new; " or: TextConverter > newForEncoding: 'mac-roman' " > Â Â Â nextPutAll: 'Ã©Ã©Ã©' ]. This is the correct way of solving your problem... however, your application becomes dependent of MacOS X. If you want your application to be portable to other OSes, I would advise you to use the simple approach that you give FileStream newFileNamed: 'test.txt' do: [ :each | each nextPutAll: 'Ã©Ã©Ã©' ] and tell your favorite Apple editor that this is indeed UTF-8. UTF-8 is the standard, MacRoman is Apple only. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

May 16, 2011

Re: [Pharo-project] Write accentuate characters in file

by Sven Van Caekenberghe

On 16 May 2011, at 16:42, Adrien BARREAU wrote: > Hello, > > A small question I have: how can I write a "Ã©" character in a file and >really< get it in Mac OS? > I tried with: > > FileStream newFileNamed: 'test.txt' do: [ :each | each nextPutAll: 'Ã©Ã©Ã©' ] > > and got: 'âÂ©âÂ©âÂ©'. > > I also tried with FileSystem and got : 'ÃÃÃ'. > > I do not see another way to do that ... > > > Regards, > Adrien. Works for me (Pharo 1.2.x , Mac OS X 10.6.x) FileStream newFileNamed: '/tmp/foo.txt' do: [ :each | each nextPutAll: 'Ã©Ã©Ã©' ]. (FileStream fileNamed: '/tmp/foo.txt') upToEnd 'Ã©Ã©Ã©' Sven

May 16, 2011

Re: [Pharo-project] Write accentuate characters in file

by Henrik Sperre Johansen

On 16.05.2011 16:42, Adrien BARREAU wrote: > Hello, > > A small question I have: how can I write a "Ã©" character in a file and > >really< get it in Mac OS? > I tried with: > > FileStream newFileNamed: 'test.txt' do: [ :each | each nextPutAll: > 'Ã©Ã©Ã©' ] > > and got: 'âÂ©âÂ©âÂ©'. That IS the Ã© character btw, in UTF8 encoding, but interpreted and displayed as MacRoman. Cheers, Henry

May 16, 2011

Re: [Pharo-project] Write accentuate characters in file

by Henrik Sperre Johansen

On 16.05.2011 16:42, Adrien BARREAU wrote: > Hello, > > A small question I have: how can I write a "Ã©" character in a file and > >really< get it in Mac OS? > I tried with: > > FileStream newFileNamed: 'test.txt' do: [ :each | each nextPutAll: > 'Ã©Ã©Ã©' ] > > and got: 'âÂ©âÂ©âÂ©'. > > I also tried with FileSystem and got : 'ÃÃÃ'. > > I do not see another way to do that ... > > > Regards, > Adrien. FileStream newFileNamed: 'test.txt' do: [ :stream | stream converter: MacRomanTextConverter new; " or: TextConverter newForEncoding: 'mac-roman' " nextPutAll: 'Ã©Ã©Ã©' ]. Cheers, Henry

May 16, 2011

[Pharo-project] Write accentuate characters in file

by Adrien BARREAU

Hello, A small question I have: how can I write a "Ã©" character in a file and >really< get it in Mac OS? I tried with: FileStream newFileNamed: 'test.txt' do: [ :each | each nextPutAll: 'Ã©Ã©Ã©' ] and got: 'âÂ©âÂ©âÂ©'. I also tried with FileSystem and got : 'ÃÃÃ'. I do not see another way to do that ... Regards, Adrien.

May 16, 2011

[Pharo-project] I give up. Squeaksource has lost lot of versions again

by Mariano Martinez Peck

or I am doing something stupid, -- Mariano http://marianopeck.wordpress.com

May 16, 2011

Re: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk implementations

by David T. Lewis

On Sun, May 15, 2011 at 07:02:56PM -0400, David T. Lewis wrote: > On Sat, May 14, 2011 at 01:13:29PM +0200, Nicolas Cellier wrote: > > > > I also have my modest bitShift: improvments pending > > (http://bugs.squeak.org/view.php?id=7109) > > Maybe I haven't performed enough tests to assert the performance gain. > > The changes are reliable, I run a VM with both improvments without > > crash for months. > > I have not looked at http://bugs.squeak.org/view.php?id=7109 yet but > will do so. > > Dave The bitShift: improvements are now in SqS/VMMaker VMMaker-dtl.234 (but not yet in oscog). All tests green for 32 and 64-bit platforms, and also for 64-bit image. Dave

May 16, 2011

Re: [Pharo-project] squeaksource is down :(

by Jorge Ressia

fixed On Mon, May 16, 2011 at 10:52 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Thanks > > -- > Mariano > http://marianopeck.wordpress.com > > -- Jorge Ressia www.jorgeressia.com

May 16, 2011

Re: [Pharo-project] Convention to build cmd-line interfaces with Pharo?

by Igor Stasenko

On 15 May 2011 17:40, Stefan Marr <pharo(a)stefan-marr.de> wrote: > > On 15 May 2011, at 14:57, StÃ©phane Ducasse wrote: > >> look into 1.3 because we made it better so that you can pass something that is not an cs or st and that >> you can specify who should handle it and not get the system barking dummily at you. > That will probably help with Pharo 1.3, thanks. > > Unfortunately, that does not help me as an application developer. > I still want to maintain compatibility with Squeak and Pharo 1.2 since that is the current stable version. > > So, I would still appreciate some guidance on what the best approach is to handle such incompatibilities. > Are there some common practices how to encapsulate these differences? > Yes. On your place i would just trash everything and implement a good command line interface from scratch. :) As you may know, Squeak was inherently designed to not care about a command-line and any stdio, so we don't have a standartized way to handle command-line and standard input/output :( I don't remember what exactly was done in 1.3. Some cleanup i guess. -- Best regards, Igor Stasenko AKA sig.

May 16, 2011

Re: [Pharo-project] out of memory - cog on windows

by Tudor Girba

Hi Igor, Thanks a lot for looking into this. For us (around Moose), this is a critical issue because we play with our models in memory and regularly have images of several hundred megabytes. While most of us work on Mac without a problem, some other people work on Windows and this is a bottleneck. Unfortunately, I do not have enough know-how to dive into the VM, but I would be gladly help in any way I can. Cheers, Doru On 16 May 2011, at 10:50, Igor Stasenko wrote: > On 10 May 2011 09:34, Tudor Girba <tudor.girba(a)gmail.com> wrote: >> Hi, >> >> I am back with some more input on the matter. We played with it, and found that basically any image that goes beyond something like 200MB limit (or maybe it's the number of objects), will not open on Windows. >> >> I would need some help on this. Has nobody else hit this wall, or is it that I am doing something wrong? >> >> One scenario that we used to reproduce the problem looks like this: >> 1. Take a Moose image: >> http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/… >> 2. Run: >> 1 to: 3 do: [ :i | MooseScripts createModelForConfigurationOfMoose ] >> This will basically create some 850000 objects and will get the image to some 400+MB >> 3. Save and quit the image >> 4. Reopen it >> >> A ready-made image with the result of this can be found here: >> http://dl.dropbox.com/u/18323746/Tmp/moose-case-study-windows-problem.zip >> >> This works well on Mac, but on Windows when you reopen the image, you get the out of memory message. >> >> Cheers, >> Doru >> >> > > I using latest VMs built by cmake on windows, and everytime i run this image, > it opens a 'Space is low' dialog and then image not reacting on anything. > VM not crashing however and responds to windows events.. But because > UI process is broken > an image simply not reacts to anything. > > > I think that the problem is that this dialog are shown at early image > startup time, > before everything is properly initialized, and because of that UI > stalls somewhere. > > > Next things which i tried is to increase a virtual memory limit in > sqWin32Alloc.h > > #ifndef MAX_VIRTUAL_MEMORY > #define MAX_VIRTUAL_MEMORY 512*1024*1024 > #endif > > first i raised it to 768 Mbytes.. same behavior. > then i raised it to 1Gb and again same behavior.. > > So, either this constant is overridden somewhere or it actually > doesn't affecting the low-space detection mechanism as i would expect. > Any suggestions? > > > I will continue looking , what happens on VM side, > but in addition to that, i think we should do something on image side as well: > - a low space watcher should not pop up before passing image startup, > because if preempted process is UI process (and in 99.99% cases it is), > then it means that low space watcher blocks UI process and as a consequence, > your image stops handling events. > > > Also, i thinking about different approach for signaling a low space condition. > Instead of signaling a low space semaphore, what VM could do is to > fail an allocation primitive > and set the error code to "low memory warning" > then a primitive failure code could actually throw an exception, which > then could be handled as usual... > so you could write a code, like: > > [ self allocateSomethingReallyHuge ] on: LowMemoryWarning do: [:err | > self shouldWeReallyCare ifFalse: [ self tellVMThatItsOk. err resume ] > ifTrue: [ err pass ] > ] > > Because by preempting a currently active process, which "possibly" > causing a memory problems is not a solution, > as you can see, if it happens during startup phase, then you it just > stucks and image hangs. > But if we could use exceptions, we could just ignore this warning (or > do something else) during image startup, > instead of blocking UI process , showing a useless popup message and > letting image hang like that. > > -- > Best regards, > Igor Stasenko AKA sig. -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

May 16, 2011