- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Running from the command line in Windows

by Sebastian Tleye

Hi Eliot, Thanks, I tried but is the same, I can run code but the result does not appear in the console. 2014-10-28 18:30 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Sebastian, > > make sure you use a console VM. You can find non-Pharo console VMs at > my site which you can test, e.g. > http://www.mirandabanda.org/files/Cog/VM/VM.r3114/cogwin-14.42.3114.zip. > The console VM is called SqueakConsole.exe > > On Tue, Oct 28, 2014 at 5:52 AM, Sebastian Tleye < > sebastian.tleye(a)gmail.com> wrote: > >> Hi, >> >> I have a little question, >> >> I need to run a piece of code from the command line, if I do the >> following in Mac it works >> >> ./Pharo --headless ../Resources/Pharo3.0.image eval '3+3' >> >> I see the result of the evaluation in the console, but if I do the same >> in Windows it runs but it doesn't show the result in the console. >> >> Any clue of why this is happening? And how to solve it? >> Thanks! >> > > > > -- > best, > Eliot > -- SebastiÃ¡n Tleye

Oct. 29, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] dd006c: 40336

by Max Leske

> On 29.10.2014, at 08:22, Marcus Denker <marcus.denker(a)gmail.com> wrote: > > > > > > > On Wednesday, Oct 29, 2014 at 8:18 am, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>, wrote: > > On 29.10.2014, at 01:17, stepharo wrote: > > > > > > Good question :). > > > I do not know I would say that having the package Unpackaged would be better than nil > @free.fr> > > So maybe the bug is that it should not be allowed to pass nil as category? > > > @free.fr> > We need the concept of âthis is code that is automatically generated, it is not part of any package and this is meant to be like thatâ. Nautilus (or RPackage?) does provide the âUnpackagedâ category. Wouldnât that be âgood enoughâ for now? > (there is now code in a package Generated-code-non-existing-package that is of that kind, but the problem is that this package is always dirty of code gets generated). > > https://pharo.fogbugz.com/f/cases/14097/generated-code-non-existing-package… > > Would be nice if someone would implement a solution for this. For libgit2 I simply sublassed NB and put the auto-generated methods into the protocols I choose. Of course thatâs not a general solution. > > > > > > On 28/10/14 16:26, Max Leske wrote: > > >> I just fixed a couple of Fuel tests that failed because it is possible to create a trait with the category set to nil. When creating a new trait with the same name this results in an exception being signaled. Should we consider this a bug? Itâs not cool to create a trait in category nil but since itâs possibleâ¦ Should I open an issue? > > >> > > >> Cheers, > > >> Max > > >> > > >> > > >>> On 28.10.2014, at 20:42, Max Leske wrote: > > >>> > > >>> Oh yeah! Maybe now the Fuel tests will be back to green :) > > >>> > > >>>> On 28.10.2014, at 20:23, stepharo wrote: > > >>>> > > >>>> Thanks esteban! > > >>>> I'm unstuck :) > > >>>> > > >>>> On 28/10/14 07:41, GitHub wrote: > > >>>>> 40336 > > >>>>> 14337 Removing a trait usage raises an exception (2nd attempt) > > >>>>> https://pharo.fogbugz.com/f/cases/14337 > > >>>> > > >> > > >> > > >> > > > > > > > > > > > > @free.fr>@gmail.com>@free.fr>

Oct. 29, 2014

Re: [Pharo-dev] Way to embed efficiently data?

by Hilaire

Hello Ronie, iStoa, an interactive math exercices books (http://istoa.drgeo.eu) comes with a lot of binary files (PNG files). To manage that, I use Smalltalk hub to host Smalltalk code, and Launchpad hosting (bazar versioning system) to host the PNG files, the SVG counterpart source of these binary files, the related user documentations, the translation files, the Bash and Smalltalk build scripts, the VM to build the end user application and any other needed data. As with any application written in other programming language, the data are loaded at runtime. Btw, a LRU cache is still needed for iStoa, but it will came later. I suggest you keep your data out of Monticello, it will be just too complicate to manage your data, particularly if it grows or need to be updated. Good work! Hilaire Le 26/10/2014 21:22, Ronie Salgado a Ã©crit : > Hello, > > I want to know if there is an efficient way to embed data with version > control on it(Monticello). > > By efficient, I mean without gzipping and Base64 encoding the data in > the source code of a method. > > Ideally, I would like this embedded data in a separate file, to avoid > memory consumption when I am not using this data. > > I am interesting on embedding text files(GLSL Shaders, OpenCL kernel > source code) and binary data (images) > > Greetings, > Ronie -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Oct. 29, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] dd006c: 40336

by Marcus Denker

On Wednesday, Oct 29, 2014 at 8:18 am, Max Leske <maxleske(a)gmail.com>, wrote: > On 29.10.2014, at 01:17, stepharo wrote: > > Good question :). > I do not know I would say that having the package Unpackaged would be better than nil Â @free.fr> So maybe the bug is that it should not be allowed to pass nil as category? @free.fr> We need the concept of âthis is code that is automatically generated, it is not part of any package and this is meant to be like thatâ.Â (there is now code in a package Generated-code-non-existing-package that is of that kind, but the problem is that this package is always dirty of code gets generated). Â https://pharo.fogbugz.com/f/cases/14097/generated-code-non-existing-package… Would be nice if someone would implement a solution for this. > > On 28/10/14 16:26, Max Leske wrote: >> I just fixed a couple of Fuel tests that failed because it is possible to create a trait with the category set to nil. When creating a new trait with the same name this results in an exception being signaled. Should we consider this a bug? Itâs not cool to create a trait in category nil but since itâs possibleâ¦ Should I open an issue? >> >> Cheers, >> Max >> >> >>> On 28.10.2014, at 20:42, Max Leske wrote: >>> >>> Oh yeah! Maybe now the Fuel tests will be back to green :) >>> >>>> On 28.10.2014, at 20:23, stepharo wrote: >>>> >>>> Thanks esteban! >>>> I'm unstuck :) >>>> >>>> On 28/10/14 07:41, GitHub wrote: >>>>> 40336 >>>>> 14337 Removing a trait usage raises an exception (2nd attempt) >>>>> https://pharo.fogbugz.com/f/cases/14337 >>>> >> >> >> > > @free.fr>@gmail.com>@free.fr>

Oct. 29, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] dd006c: 40336

by Max Leske

> On 29.10.2014, at 01:17, stepharo <stepharo(a)free.fr> wrote: > > Good question :). > I do not know I would say that having the package Unpackaged would be better than nil So maybe the bug is that it should not be allowed to pass nil as category? > > On 28/10/14 16:26, Max Leske wrote: >> I just fixed a couple of Fuel tests that failed because it is possible to create a trait with the category set to nil. When creating a new trait with the same name this results in an exception being signaled. Should we consider this a bug? Itâs not cool to create a trait in category nil but since itâs possibleâ¦ Should I open an issue? >> >> Cheers, >> Max >> >> >>> On 28.10.2014, at 20:42, Max Leske <maxleske(a)gmail.com> wrote: >>> >>> Oh yeah! Maybe now the Fuel tests will be back to green :) >>> >>>> On 28.10.2014, at 20:23, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> Thanks esteban! >>>> I'm unstuck :) >>>> >>>> On 28/10/14 07:41, GitHub wrote: >>>>> 40336 >>>>> 14337 Removing a trait usage raises an exception (2nd attempt) >>>>> https://pharo.fogbugz.com/f/cases/14337 >>>> >> >> >> > >

Oct. 29, 2014

Re: [Pharo-dev] AioPlugin is back in linux VMs

by David T. Lewis

On Tue, Oct 28, 2014 at 06:53:49PM +0200, kilon alios wrote: > whats the purpose of the plugin ? How we can test it ? AioPlugin provides support for asynchronous IO event notification. When an external IO event occurs, the event registration causes a Smalltalk semaphore to be signaled. A process can wait on this semaphore, thereby acting as an event handler for the external event. Code for the plugin is at http://www.squeaksource.com/AioPlugin. For testing and examples, see class AioEventHandlerExample in package OSProcess, and AioEventHandlerTestCase in OSProcess-Tests. Dave > > On Tue, Oct 28, 2014 at 6:51 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > Hi, > > > > I reintroduced AioPlugin into the linux VM. > > In Mac it is there since always. > > In windows is irrelevant. > > > > So well, if you use linux and download the latest vm, you can play with it > > and check that everything is ok (or the contrary) :) > > > > Esteban > >

Oct. 29, 2014

Re: [Pharo-dev] Command Shell in Pharo 4

by David T. Lewis

Hi Kilon, On Tue, Oct 28, 2014 at 02:12:12PM +0200, kilon alios wrote: > Why not use default as I did ? why the font needs to be fixed ? I am sorry > I am not familiar with fonts in pharo so much, I did not even know what > bitmap font is before I joined Pharo. For me it makes more sense to use the > default because then it will use what the user have chosen in pharo > settings. I am not sure that I am reading your question correctly, but the reason for selecting a fixed font rather than a proportional font is that it provides a nice display output for many of the unix command line tools. Back in the day, a terminal was a device with fixed width character displays, and programs that write to the display would often format the output data so that it would print nicely on a display or printer with fixed width character cells. The CommandShell window is a simple emulation of devices like this. It tries to use a fixed width font so that a unix utility command will display output in the expected character positions. In Squeak, TextStyle named: 'DefaultFixedTextStyle' answers a reasonable looking fixed width font, so that's what I use as the default. If no reasonable fixed font was available, I fell back on TextStyle default. The Pharo image that I am looking at now seems to answer a proportional font as its DefaultFixedTextStyle, so maybe there is something that needs to be fixed there. By the way, if you enter this in your CommandShell window, you will find that it is evaluated as a Smalltalk expression rather than as a unix shell command: $ TextStyle named: 'DefaultFixedTextStyle' a TextStyle Bitmap DejaVu Sans 7 $ That's one of the things I was trying to do with CommandShell, mix up Smalltalk expression evaluation with unix commands, and be able to mix them up in unix command pipelines like this: $ { #one. #two . #three . Smalltalk . true } ! | cat {#one. #two. #three. Smalltalk. true} $ > > I dont know if you noticed my reply but I did use pwd and did try to run > the script with the bash command. it looks like that pwd is not in sync > with what Command Shell thinks as its current working directory , actually > my bash file complained that the tool tried to run the script from the path > of the actual pharo image which should not be the case . IIRC, there have been some changes made in Pharo versus Squeak that affect default working directories, possibly the image directory as opposed to the VM directory. I don't recall the details, but you may be seeing some issue related to that. CommandShell tries to start with some initial working directory, but it keeps track of its own current working directory after it has started. This works very differently on Unix and Windows, so it was necessary to keep track of it independent of what the image and/or VM were using as defaults. It may be that changes in Pharo have affected this, or maybe you are seeing issues related to OS X, I'm not sure. > > By the way congratulation on your tool, I see you have put a lot of effort > in it and I am impressed by the amount of code and how well its organised. > I will definetly keep exploring the code and further improve it if I can :) > Thanks! It was sort of a hobby experiment, so don't expect it to be a professional grade replacement for /bin/bash ;-) Dave

Oct. 29, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] dd006c: 40336

by stepharo

Good question :). I do not know I would say that having the package Unpackaged would be better than nil On 28/10/14 16:26, Max Leske wrote: > I just fixed a couple of Fuel tests that failed because it is possible to create a trait with the category set to nil. When creating a new trait with the same name this results in an exception being signaled. Should we consider this a bug? Itâs not cool to create a trait in category nil but since itâs possibleâ¦ Should I open an issue? > > Cheers, > Max > > >> On 28.10.2014, at 20:42, Max Leske <maxleske(a)gmail.com> wrote: >> >> Oh yeah! Maybe now the Fuel tests will be back to green :) >> >>> On 28.10.2014, at 20:23, stepharo <stepharo(a)free.fr> wrote: >>> >>> Thanks esteban! >>> I'm unstuck :) >>> >>> On 28/10/14 07:41, GitHub wrote: >>>> 40336 >>>> 14337 Removing a trait usage raises an exception (2nd attempt) >>>> https://pharo.fogbugz.com/f/cases/14337 >>> > > >

Oct. 29, 2014

Re: [Pharo-dev] Super fast delay

by Sven Van Caekenberghe

I am pretty sure that it is related to virtual hardware, it seems to work reliably on my mac: prometheus:pharo4 sven$ ./pharo Pharo.image printVersion [version] 4.0 #40322 prometheus:pharo4 sven$ time ./pharo Pharo.image eval '5 seconds asDelay wait' a Delay(5000 msecs) real 0m5.504s user 0m0.491s sys 0m0.440s prometheus:pharo4 sven$ time ./pharo Pharo.image eval '5 seconds asDelay wait' a Delay(5000 msecs) real 0m5.539s user 0m0.408s sys 0m0.166s prometheus:pharo4 sven$ time ./pharo Pharo.image eval '5 seconds asDelay wait' a Delay(5000 msecs) real 0m6.022s user 0m0.647s sys 0m0.442s prometheus:pharo4 sven$ time ./pharo Pharo.image eval '5 seconds asDelay wait' a Delay(5000 msecs) real 0m5.539s user 0m0.518s sys 0m0.440s But how it can work so completely bogus on virtual hardware beats me. > On 28 Oct 2014, at 20:21, phil(a)highoctane.be wrote: > > VMWare Workstation 10 on Win8.1 Pro > PharoVM compiled on CentOS6.5 > > [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' > a Delay(5000 msecs) > > real 0m0.473s <-- not much... > user 0m0.285s > sys 0m0.140s > [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' > a Delay(5000 msecs) > > real 0m0.360s <-- not much either > user 0m0.257s > sys 0m0.095s > [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' > a Delay(5000 msecs) > > real 0m0.374s > user 0m0.269s > sys 0m0.103s > [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' > > a Delay(5000 msecs) > > real 0m5.324s > user 0m0.338s > sys 0m0.067s > [philippeback@CENTOSDEV zeroconf-centos]$ > [philippeback@CENTOSDEV zeroconf-centos]$ ^C <--- FROZEN!!!! > > > [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' > a Delay(5000 msecs) > > real 0m0.468s > user 0m0.287s > sys 0m0.171s > [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' > a Delay(5000 msecs) > > real 0m0.639s > user 0m0.281s > sys 0m0.233s > [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' > a Delay(5000 msecs) > > real 0m0.331s > user 0m0.260s > sys 0m0.066s > [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' > a Delay(5000 msecs) > > real 0m0.493s > user 0m0.265s > sys 0m0.210s > [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' > a Delay(5000 msecs) > > real 0m0.343s > user 0m0.258s > sys 0m0.073s > [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' > a Delay(5000 msecs) > > real 0m0.352s > user 0m0.314s > sys 0m0.035s > [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' > a Delay(5000 msecs) > > real 0m0.303s > user 0m0.266s > sys 0m0.032s > > > Completely un[reliable|predictable]... > > Phil > > # time ./pharo Pharo.image eval '5 asSeconds asDelay wait' > a Delay(5000 msecs) > > real 0m0.696s > user 0m0.580s > sys 0m0.060s > > # time ./pharo Pharo.image eval '5 asSeconds asDelay wait' > a Delay(5000 msecs) > > real 0m5.755s > user 0m0.812s > sys 0m0.080s > > Weird ! > > Must have something todo with virtual hardware ... > > > On 28 Oct 2014, at 18:24, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > I just recognized that Delay is working in a strange way on my linux box > > > > $ time pharo-vm-nox ./Pharo.image eval "(Delay forSeconds: 5) wait" > > a Delay(5000 msecs) > > > > real 0m0.158s > > user 0m0.136s > > sys 0m0.020s > > > > I use the vm from the ppa. What do you get when you execute it? > > > > Norbert > > > > >

Oct. 28, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] dd006c: 40336

by Max Leske

I just fixed a couple of Fuel tests that failed because it is possible to create a trait with the category set to nil. When creating a new trait with the same name this results in an exception being signaled. Should we consider this a bug? Itâs not cool to create a trait in category nil but since itâs possibleâ¦ Should I open an issue? Cheers, Max > On 28.10.2014, at 20:42, Max Leske <maxleske(a)gmail.com> wrote: > > Oh yeah! Maybe now the Fuel tests will be back to green :) > >> On 28.10.2014, at 20:23, stepharo <stepharo(a)free.fr> wrote: >> >> Thanks esteban! >> I'm unstuck :) >> >> On 28/10/14 07:41, GitHub wrote: >>> 40336 >>> 14337 Removing a trait usage raises an exception (2nd attempt) >>> https://pharo.fogbugz.com/f/cases/14337 >> >> >

Oct. 28, 2014