March 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] MemoryFileSystemFile>>#readStream forces String

by Sven Van Caekenberghe

> On 01 Mar 2016, at 07:07, stepharo <stepharo(a)free.fr> wrote: > > Hi sven > > I would like to get Xtreams (with a slightly modified API - no ++ and --) in Pharo 6.0. Yes that would be a good idea. > So I hope that we will be able to clean the stream part of Pharo. But the problem is the users of streams. The stream API is too wide, people expect hundreds of methods to be there, mixing characters and bytes, encodings, line end conventions, infinite buffering, arbitrary positioning, and so on. Many of these characteristics can be elegantly composed, just when you need then. Right now we have some cool streams in the image, with minimal APIs, targeted at just one function. Like Guile's new file streams, the Zn streams, Zdc socket streams, we just have to use them. > Stef > > > Le 29/2/16 23:06, Sven Van Caekenberghe a Ã©crit : >>> On 29 Feb 2016, at 20:27, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: >>> >>> All, >>> >>> is there any reason why MemoryFileSystemFile>>#readStream forces it's content to a String (#aString)? >>> >>> readStream >>> ^ ReadStream on: self bytes asString from: 1 to: size >>> >>> I'm parsing XML files from an in-memory ZIP Archive and had some real problem with non-ASCII characters. Took me some while to figure out reading from the in-memory-archive returns a String. This prevents the XML Parser from doing a PI based decoding (utf-8 in this case). >> I think it is not good to do this, better stick with bytes. >> >> Primitive streams should be binary only, interpreting them as characters is easily done wrapping a ZnCharacter[Read|Write]Stream on them. >> >> But this whole situation is a mess. >> >>> Just as a sidenote: Although the GT-Spotter/XML Integration relies on FileReference it assumes that the file is in the DiskFilesystem (some methods only pass a Path). Is this intentional? If not I'd try to fix it on the run. >>> >>> Thanks, >>> >>> Udo >>> >>> >> >> > >

March 1, 2016

Re: [Pharo-dev] removing of TestReviver

by Marcus Denker

> On 26 Feb 2016, at 16:50, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Hi, > > TestReviver that is a part of HudsonBuildTools20 and it is a tool that can process Fuel files generated by CI server. It is an UI tool dependent on Spec so it adds some mess to headless images without GUI that need to use HudsonBuildTools for SUnit reports. > I propose to remove it from the standard image and move it to a separate SmalltalkHub project. It is not used directly in Pharo and will be easy to load it from the Catalog by people who need such functionality. > Yes, tools should be separate from the base. We should rename HudsonBuildTools in JenkinsBuildTools, tooâ¦ Marcus

March 1, 2016

Re: [Pharo-dev] What is the limit of prespur VM memory under Windows?

by ClÃ©ment Bera

2016-02-29 19:25 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi ClÃ©ment, > > > On Feb 29, 2016, at 10:01 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > No. > > The limit is supposed to be around 500 Mb on windows or 1 Gb for some > specifically compiled VMs. 1 Gb VM may not start on windows, you may need > to restart the computer before. > > > IIRC the default limit is 512Mb and that can be raised on the command line > (or in an ini file ?). > > But I think that at least Windows xo has a 2gb preprocessor limit by > default. I remember that to go higher one needed to change how the system > booted in win.ini. See eg > https://knowledge.autodesk.com/support/autocad/troubleshooting/caas/sfdcart… > > yes you can change the .ini file. But in a deployed application on windows for a Synectique customer they use 2Gb and sometimes windows doesn't want to start the app, as a work around they found out that windows always agrees to start the app just after being reboot. So the .ini file is good on Unix to allow 2Gb instead of the default 1 Gb, but on windows there are additionnal problems. So the Spur VM is really the best solution anyway. > > To bypass the limit the best way is to use a spur VM honestly. Spur32VMs > are limited to around 2.7Gb on Windows. > > > +1 :) > > _,,,^..^,,,_ (phone) > > 2016-02-29 18:53 GMT+01:00 Blondeau Vincent < > vincent.blondeau(a)worldline.com>: > >> Hi, >> >> >> >> I am confronted with a memory issue under Windows. >> >> I have an image of 745Mo with a Moose model, and I cannot instantiate a string of 30Mo: I get a OutOfMemoryException. >> >> The theoretical limit is 2Go, isnât it? >> >> >> >> I have a prespur vm under a Windows 64 bits: >> >> Smalltalk vm version: >> >> 'NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: >> 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Dec 3 2015 >> >> NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: >> 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Dec 3 2015 >> >> https://github.com/pharo-project/pharo-vm.git Commit: >> 28d077d8df494ce050ca42c97c892471e8b8740c Date: 2015-10-16 12:02:43 +0200 >> By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #15019 >> >> I set in Pharo.ini: AddressSpaceLimit=2000000000 >> >> >> >> What can I do to bypass the issue? >> >> >> >> >> >> Thanks in advance, >> >> Vincent >> >> >> >> >> !!!************************************************************************************* >> "Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã >> l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par >> le secret professionnel. Si vous recevez ce message par erreur, merci d'en >> avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du >> message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de >> Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien >> que les meilleurs efforts soient faits pour maintenir cette transmission >> exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et >> sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant >> d'un virus transmis. >> >> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive this >> e-mail in error, please notify the sender immediately and destroy it. As >> its integrity cannot be secured on the Internet, the Worldline liability >> cannot be triggered for the message content. Although the sender endeavours >> to maintain a computer virus-free network, the sender does not warrant that >> this transmission is virus-free and will not be liable for any damages >> resulting from any virus transmitted.!!!" >> > >

March 1, 2016

Re: [Pharo-dev] MemoryFileSystemFile>>#readStream forces String

by stepharo

Hi sven I would like to get Xtreams (with a slightly modified API - no ++ and --) in Pharo 6.0. So I hope that we will be able to clean the stream part of Pharo. Stef Le 29/2/16 23:06, Sven Van Caekenberghe a Ã©crit : >> On 29 Feb 2016, at 20:27, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: >> >> All, >> >> is there any reason why MemoryFileSystemFile>>#readStream forces it's content to a String (#aString)? >> >> readStream >> ^ ReadStream on: self bytes asString from: 1 to: size >> >> I'm parsing XML files from an in-memory ZIP Archive and had some real problem with non-ASCII characters. Took me some while to figure out reading from the in-memory-archive returns a String. This prevents the XML Parser from doing a PI based decoding (utf-8 in this case). > I think it is not good to do this, better stick with bytes. > > Primitive streams should be binary only, interpreting them as characters is easily done wrapping a ZnCharacter[Read|Write]Stream on them. > > But this whole situation is a mess. > >> Just as a sidenote: Although the GT-Spotter/XML Integration relies on FileReference it assumes that the file is in the DiskFilesystem (some methods only pass a Path). Is this intentional? If not I'd try to fix it on the run. >> >> Thanks, >> >> Udo >> >> > >

March 1, 2016

Re: [Pharo-dev] MemoryFileSystemFile>>#readStream forces String

by Max Leske

We introduced #binaryReadStream and friends as a work around in Pharo 4. The reason we didnât fix the problem properly is that weâve been waiting for the introduction of XStreams in hopes of getting a cleaner stream API. Max > On 29 Feb 2016, at 23:06, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 29 Feb 2016, at 20:27, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: >> >> All, >> >> is there any reason why MemoryFileSystemFile>>#readStream forces it's content to a String (#aString)? >> >> readStream >> ^ ReadStream on: self bytes asString from: 1 to: size >> >> I'm parsing XML files from an in-memory ZIP Archive and had some real problem with non-ASCII characters. Took me some while to figure out reading from the in-memory-archive returns a String. This prevents the XML Parser from doing a PI based decoding (utf-8 in this case). > > I think it is not good to do this, better stick with bytes. > > Primitive streams should be binary only, interpreting them as characters is easily done wrapping a ZnCharacter[Read|Write]Stream on them. > > But this whole situation is a mess. > >> Just as a sidenote: Although the GT-Spotter/XML Integration relies on FileReference it assumes that the file is in the DiskFilesystem (some methods only pass a Path). Is this intentional? If not I'd try to fix it on the run. >> >> Thanks, >> >> Udo >> >> > >

March 1, 2016

Re: [Pharo-dev] [squeak-dev] Raspberry Pi 3 & Squeak

by Ben Coman

On Tue, Mar 1, 2016 at 10:16 AM, tim Rowledge <tim(a)rowledge.org> wrote: > Yes, COG runs on Pi 3; no, not as an ARM64 application, nor does it generate ARM64 instructions. Yes, it could. Yes, it may well do so sometime soon; yes, one meeeeeeellion dollars. > > Performance is obviously improved over the Pi2. Not completely sure as yet since I have a prototype not a production machine. > > Pi 3 is still $35 plus tax/shipping/etc. See https://www.raspberrypi.org/blog/raspberry-pi-3-on-sale/ for details. Great to hear. Coincidentally, I heard about the Pi3 last night and ordered one due to ship 7 march. Built-in wireless and more GPIO pins are nice. I found an interesting comparison of ARM A7 and A53 http://www.anandtech.com/show/8718/the-samsung-galaxy-note-4-exynos-review/3 Also I was suddenly disappointed that I had bought a Pine64, but I was happy to read this balanced report that it retains some advantages... http://forum.pine64.org/archive/index.php?thread-379.html cheers -ben

March 1, 2016