- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Sugar-devel] Dr.Geo on XO 1

by StÃ©phane Ducasse

Ok so we will see because this is important. I will discuss with igor about it. Now we are preparing the conference. Stef > Bert mentionned: > > I could also reproduce it in a virtual Ubuntu 12 with 768 MB RAM (!) but > no swap. Top reports: > > Mem: 766204k total, 601588k used, 164616k free, 45624k buffers > Swap: 0k total, 0k used, 0k free, 277024k cached > > but DrGeo still crashes. > > OTOH, Etoys runs fine using the same Squeak VM on the same system (and > on XO-1). So I wonder what the new DrGeo does differently ... > > The image is in this zip archive > https://gforge.inria.fr/frs/download.php/30585/DrGeoII-12.04.xo > > Hilaire > > > Le 21/05/2012 10:51, StÃ©phane Ducasse a Ã©crit : >>>> I could also reproduce it in a virtual Ubuntu 12 with 768 MB RAM (!) but no swap. Top reports: >>>> >>>> Mem: 766204k total, 601588k used, 164616k free, 45624k buffers >>>> Swap: 0k total, 0k used, 0k free, 277024k cached >>>> >>>> but DrGeo still crashes. >>>> >>>> OTOH, Etoys runs fine using the same Squeak VM on the same system (and on XO-1). So I wonder what the new DrGeo does differently ... >>>> > >

May 21, 2012

Re: [Pharo-project] Place to sleep Lille?

by Pavel Krivanek

If someone will need a bed on thursday night, let me know. It's on Olivarius Apart Hotel next to Inria. -- Pavel On Mon, May 21, 2012 at 5:24 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On May 21, 2012, at 1:27 PM, Stephan Eggermont wrote: > > > Hi, > > > > Hmm. I'm a bit late to make a hotel reservation. Most hotels seem to be > > booked out. Anyone know an alternative? I'm arriving by train on > wednesday. > > Couch would do. > > Sadly my couch is already booked... > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > > >

May 21, 2012

Re: [Pharo-project] what is the magic with MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. ' ?

by Dale Henrichs

The immediate impact of this is that you wont' be able to use the packages in your image in a three way merge, because the system will no longer be able to find a common ancestor. By implication you shouldn't save any of the packages either, because you risk polluting the "package pool" with ancestor-less versions. I've done a little experimentation with this in the git work (at one point in time, I was not saving the ancestry information on disk) ... If you somehow record the immediate ancestor(s) of the package, you can restore the ancestry chain with the MonticelloBrowser 'adopt' operation and then you can do the merge or save the package ... You can save and load these puppies ... I'm pretty sure that the ancestry is used only for merging ... oh yeah, the name of the package with the author and version number is derived from the first ancestor, i.e., the package that was loaded into the image, while this doesn't cause explicit problems, it can be unsettling ... At least that's what I recall.... Dale ----- Original Message ----- | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> | To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> | Sent: Monday, May 21, 2012 10:58:23 AM | Subject: [Pharo-project] what is the magic with MCVersionInfo allInstances do: [ :each | each instVarNamed: | 'ancestors' put: nil ]. ' ? | | Hi guys. Can a MC guy tell me what happens when I do: | | MCVersionInfo allInstances do: [ :each | each instVarNamed: | 'ancestors' put: nil ]. | | what is what is actually clean? is that useful? what are the | consequences/impact when I do that? is my image broken? can I still | use monticello browser and all my projects with it? | | thanks | | -- | Mariano | http://marianopeck.wordpress.com | |

May 21, 2012

Re: [Pharo-project] [Sugar-devel] Dr.Geo on XO 1

by Hilaire Fernandes

Bert mentionned: I could also reproduce it in a virtual Ubuntu 12 with 768 MB RAM (!) but no swap. Top reports: Mem: 766204k total, 601588k used, 164616k free, 45624k buffers Swap: 0k total, 0k used, 0k free, 277024k cached but DrGeo still crashes. OTOH, Etoys runs fine using the same Squeak VM on the same system (and on XO-1). So I wonder what the new DrGeo does differently ... The image is in this zip archive https://gforge.inria.fr/frs/download.php/30585/DrGeoII-12.04.xo Hilaire Le 21/05/2012 10:51, StÃ©phane Ducasse a Ã©crit : >>> I could also reproduce it in a virtual Ubuntu 12 with 768 MB RAM (!) but no swap. Top reports: >>> >>> Mem: 766204k total, 601588k used, 164616k free, 45624k buffers >>> Swap: 0k total, 0k used, 0k free, 277024k cached >>> >>> but DrGeo still crashes. >>> >>> OTOH, Etoys runs fine using the same Squeak VM on the same system (and on XO-1). So I wonder what the new DrGeo does differently ... >>>

May 21, 2012

[Pharo-project] what is the magic with MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. ' ?

by Mariano Martinez Peck

Hi guys. Can a MC guy tell me what happens when I do: MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. what is what is actually clean? is that useful? what are the consequences/impact when I do that? is my image broken? can I still use monticello browser and all my projects with it? thanks -- Mariano http://marianopeck.wordpress.com

May 21, 2012

Re: [Pharo-project] 57 registered people for the pharo conf

by Sean P. DeNigris

StÃ©phane Ducasse wrote > > We are happy to say that there are 57 participants to the pharo conf > starting thursday. > Man, I'm so jealous!! Have fun :) It'd be really awesome if the presentations could be recorded. Even an iPhone recording would be better than missing the whole thing... Sean -- View this message in context: http://forum.world.st/57-registered-people-for-the-pharo-conf-tp4631213p463… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 21, 2012

Re: [Pharo-project] STDIO on Win

by Igor Stasenko

On 21 May 2012 19:01, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Sun, May 20, 2012 at 6:52 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 21 May 2012 03:29, Igor Stasenko <siguctua(a)gmail.com> wrote: >> > On 21 May 2012 02:16, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> >> >> >> >> On Sun, May 20, 2012 at 4:59 PM, Igor Stasenko <siguctua(a)gmail.com> >> >> wrote: >> >>> >> >>> On 20 May 2012 21:34, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >>> > HiÂ Torsten, >> >>> > >> >>> > On Sun, May 20, 2012 at 11:51 AM, Torsten Bergmann <astares(a)gmx.de> >> >>> > wrote: >> >>> >> >> >>> >> Hi, >> >>> >> >> >>> >> havent yet played with the latest stdin/stdout stuff. >> >>> >> Does this already work on Windows? >> >>> >> >> >>> >> At least I tried >> >>> >> >> >>> >> FileStream stdout nextPutAll: 'Yopla' >> >>> >> >> >>> >> in the latest 2.0 after starting Pharo-2.0-one-click.bat. >> >>> >> Gives an error (write failed). >> >>> >> >> >>> >> Any comments? >> >>> > >> >>> > >> >>> > It works in my console VMs. Â If you download >> >>> > >> >>> > e.g.Â http://www.mirandabanda.org/files/Cog/VM/VM.r2550/cogwin.zipÂ you >> >>> > need >> >>> > to run CroquetConsole.exe in a DOS or Cygwin window. Â Using the >> >>> > normal >> >>> > VM >> >>> > does *not* work, since that's the way Windows is "designed". >> >>> > >> >>> Nope. It just requires some work :) >> >> >> >> >> >> Come on :) Â The program opening up a completely different console isn't >> >> what >> >> I'd call working. Â And if the program is in a pipe ist must stay in a >> >> pipe. >> >> Â Its an easy thing to have a console VM, e.g. run from a script. >> >> >> >> >> > >> > Here, what i found (windoze 7/ gcc 4.6.1). >> > >> > Test code (test.c) - note the entry point is WinMain() , not main() : >> > --------------------- >> > #include <windows.h> >> > #include <stdio.h> >> > >> > int APIENTRY Â WinMain( >> > Â HINSTANCE hInstance, >> > Â Â HINSTANCE hPrevInstance, >> > Â Â LPSTR lpCmdLine, >> > Â Â int nCmdShow >> > ) >> > { >> > Â Â Â Â FILE *f; >> > Â Â Â Â STARTUPINFO info; >> > Â Â Â Â GetStartupInfo( &info); >> > >> > >> > >> > Â Â Â Â f = fopen("test.out","w"); >> > >> > Â Â Â Â fprintf(f, "stdin: %d stdout: %d stderr: %d\n", info.hStdInput , >> > info.hStdOutput, info.hStdError); >> > >> > Â Â Â Â fprintf(f, "STD handles: stdin: %d stdout: %d stderr: %d\n", >> > GetStdHandle(STD_INPUT_HANDLE) , GetStdHandle(STD_OUTPUT_HANDLE) , >> > Â Â Â Â Â Â Â Â GetStdHandle(STD_ERROR_HANDLE)); >> > >> > Â Â Â Â fclose(f); >> > Â return 0; >> > } >> > --------------------- >> > >> > >> > gcc test.c >> > >> > >> > Running from mingw bash shell: >> > >> > a.exe >> > >> > stdin: 11 stdout: 23 stderr: 27 >> > STD handles: stdin: 11 stdout: 23 stderr: 27 >> > >> > a.exe < test.c >> > >> > >> > stdin: 168 stdout: 23 stderr: 27 >> > STD handles: stdin: 168 stdout: 23 stderr: 27 >> > >> > a.exe | less >> > >> > stdin: 11 stdout: 328 stderr: 27 >> > STD handles: stdin: 11 stdout: 328 stderr: 27 >> > >> > Running from cmd shell: >> > >> > a.exe >> > >> > stdin: -1 stdout: -1 stderr: -1 >> > STD handles: stdin: 3 stdout: 39 stderr: 15 >> > >> > a.exe < test.c >> > >> > stdin: -1 stdout: -1 stderr: -1 >> > STD handles: stdin: 80 stdout: 39 stderr: 15 >> > >> > a.exe | more >> > >> > stdin: -1 stdout: -1 stderr: -1 >> > STD handles: stdin: 3 stdout: 108 stderr: 15 >> > >> > Running from explorer: >> > >> > stdin: -1 stdout: -1 stderr: -1 >> > STD handles: stdin: 3 stdout: 7 stderr: 11 >> > >> > >> > ***** >> > Â Now, if i compile with: >> > >> > gcc test.c -mwindows >> > >> > >> > under bash : >> > >> > a.exe >> > >> > stdin: 11 stdout: 23 stderr: 27 >> > STD handles: stdin: 11 stdout: 23 stderr: 27 >> > >> > under cmd >> > >> > stdin: -1 stdout: -1 stderr: -1 >> > STD handles: stdin: 3 stdout: 39 stderr: 15 >> > >> > from explorer: >> > >> > stdin: 0 stdout: 65537 stderr: 0 >> > STD handles: stdin: 0 stdout: 0 stderr: 0 >> > >> > >> > Conclusion: >> > Â - do not use -mwindows >> >> ehh.. if not used, it will open annoying console window, since >> -mconsole is default... >> however, as you can see, if you run exe from shell, the handles are there. >> So, you can use single binary (compiled with -mwindows) for both >> shell/explorer interaction, >> and you can actually detect where it runs from by checking contents of >> STARTUPINFO struct. > > > If you can figure out how to suppress the annoying console window then I'd > use a single executable. > please read my post again. i said that binary compiled with -mwindows can be used both for console and explorer interaction(s). all you need is to rebind std handles to C .. btw there's actually already parts of code which using GetStdHandle(): void SetupStderr() { TCHAR tmpName[MAX_PATH+1]; *stderrName = *stdoutName = 0; /* re-open stdout && stderr */ GetTempPath(MAX_PATH,tmpName); if(GetStdHandle(STD_ERROR_HANDLE) == INVALID_HANDLE_VALUE) { GetTempFileName(tmpName,TEXT("sq"),0,stderrName); freopen(stderrName,"w+t",stderr); } else *stderrName = 0; if(GetStdHandle(STD_OUTPUT_HANDLE) == INVALID_HANDLE_VALUE) { GetTempFileName(tmpName,TEXT("sq"),0,stdoutName); freopen(stdoutName,"w+t",stdout); } else *stdoutName = 0; } ---- but it looks like there is no callers and it does redirection if handles are invalid. if they are valid, i think they should be already set up correctly and if not, in the link which i put first in this topic, it is clear how to do it: (http://dslweb.nwnexus.com/~ast/dload/guicon.htm) // redirect unbuffered STDOUT to the console lStdHandle = (long)GetStdHandle(STD_OUTPUT_HANDLE); hConHandle = _open_osfhandle(lStdHandle, _O_TEXT); fp = _fdopen( hConHandle, "w" ); *stdout = *fp; setvbuf( stdout, NULL, _IONBF, 0 ); ------------- so, if VM runs from console, there should be an access to its stdin/out/err as you normally expect from posix environment. if VM started from explorer -> there will be no stdin/out/err handles bound to process, then we can simply redirect all to /dev/null or to some file, like SetupStderr() function does. (http://stackoverflow.com/questions/313111/dev-null-in-windows) -- Best regards, Igor Stasenko.

May 21, 2012

Re: [Pharo-project] STDIO on Win

by Eliot Miranda

On Sun, May 20, 2012 at 6:52 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 21 May 2012 03:29, Igor Stasenko <siguctua(a)gmail.com> wrote: > > On 21 May 2012 02:16, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >> > >> > >> On Sun, May 20, 2012 at 4:59 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >>> > >>> On 20 May 2012 21:34, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >>> > Hi Torsten, > >>> > > >>> > On Sun, May 20, 2012 at 11:51 AM, Torsten Bergmann <astares(a)gmx.de> > >>> > wrote: > >>> >> > >>> >> Hi, > >>> >> > >>> >> havent yet played with the latest stdin/stdout stuff. > >>> >> Does this already work on Windows? > >>> >> > >>> >> At least I tried > >>> >> > >>> >> FileStream stdout nextPutAll: 'Yopla' > >>> >> > >>> >> in the latest 2.0 after starting Pharo-2.0-one-click.bat. > >>> >> Gives an error (write failed). > >>> >> > >>> >> Any comments? > >>> > > >>> > > >>> > It works in my console VMs. If you download > >>> > e.g. http://www.mirandabanda.org/files/Cog/VM/VM.r2550/cogwin.zip > you > >>> > need > >>> > to run CroquetConsole.exe in a DOS or Cygwin window. Using the > normal > >>> > VM > >>> > does *not* work, since that's the way Windows is "designed". > >>> > > >>> Nope. It just requires some work :) > >> > >> > >> Come on :) The program opening up a completely different console isn't > what > >> I'd call working. And if the program is in a pipe ist must stay in a > pipe. > >> Its an easy thing to have a console VM, e.g. run from a script. > >> > >> > > > > Here, what i found (windoze 7/ gcc 4.6.1). > > > > Test code (test.c) - note the entry point is WinMain() , not main() : > > --------------------- > > #include <windows.h> > > #include <stdio.h> > > > > int APIENTRY WinMain( > > HINSTANCE hInstance, > > HINSTANCE hPrevInstance, > > LPSTR lpCmdLine, > > int nCmdShow > > ) > > { > > FILE *f; > > STARTUPINFO info; > > GetStartupInfo( &info); > > > > > > > > f = fopen("test.out","w"); > > > > fprintf(f, "stdin: %d stdout: %d stderr: %d\n", info.hStdInput , > > info.hStdOutput, info.hStdError); > > > > fprintf(f, "STD handles: stdin: %d stdout: %d stderr: %d\n", > > GetStdHandle(STD_INPUT_HANDLE) , GetStdHandle(STD_OUTPUT_HANDLE) , > > GetStdHandle(STD_ERROR_HANDLE)); > > > > fclose(f); > > return 0; > > } > > --------------------- > > > > > > gcc test.c > > > > > > Running from mingw bash shell: > > > > a.exe > > > > stdin: 11 stdout: 23 stderr: 27 > > STD handles: stdin: 11 stdout: 23 stderr: 27 > > > > a.exe < test.c > > > > > > stdin: 168 stdout: 23 stderr: 27 > > STD handles: stdin: 168 stdout: 23 stderr: 27 > > > > a.exe | less > > > > stdin: 11 stdout: 328 stderr: 27 > > STD handles: stdin: 11 stdout: 328 stderr: 27 > > > > Running from cmd shell: > > > > a.exe > > > > stdin: -1 stdout: -1 stderr: -1 > > STD handles: stdin: 3 stdout: 39 stderr: 15 > > > > a.exe < test.c > > > > stdin: -1 stdout: -1 stderr: -1 > > STD handles: stdin: 80 stdout: 39 stderr: 15 > > > > a.exe | more > > > > stdin: -1 stdout: -1 stderr: -1 > > STD handles: stdin: 3 stdout: 108 stderr: 15 > > > > Running from explorer: > > > > stdin: -1 stdout: -1 stderr: -1 > > STD handles: stdin: 3 stdout: 7 stderr: 11 > > > > > > ***** > > Now, if i compile with: > > > > gcc test.c -mwindows > > > > > > under bash : > > > > a.exe > > > > stdin: 11 stdout: 23 stderr: 27 > > STD handles: stdin: 11 stdout: 23 stderr: 27 > > > > under cmd > > > > stdin: -1 stdout: -1 stderr: -1 > > STD handles: stdin: 3 stdout: 39 stderr: 15 > > > > from explorer: > > > > stdin: 0 stdout: 65537 stderr: 0 > > STD handles: stdin: 0 stdout: 0 stderr: 0 > > > > > > Conclusion: > > - do not use -mwindows > > ehh.. if not used, it will open annoying console window, since > -mconsole is default... > however, as you can see, if you run exe from shell, the handles are there. > So, you can use single binary (compiled with -mwindows) for both > shell/explorer interaction, > and you can actually detect where it runs from by checking contents of > STARTUPINFO struct. > If you can figure out how to suppress the annoying console window then I'd use a single executable. > > > - use GetStdHandle() for reliable results. > > > > -- > > Best regards, > > Igor Stasenko. > > > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

May 21, 2012

[Pharo-project] 57 registered people for the pharo conf

by StÃ©phane Ducasse

Hi guys We are happy to say that there are 57 participants to the pharo conf starting thursday. http://rmod.lille.inria.fr/web/pier/Events Stef

May 21, 2012

[Pharo-project] [update 2.0] #20086

by Marcus Denker

20086 ----- Issue 5930: New versions of Spec http://code.google.com/p/pharo/issues/detail?id=5930 Issue 5925: Lots of undeclared ivars http://code.google.com/p/pharo/issues/detail?id=5925 Issue 5911: Float floorLog: 2 could be exact http://code.google.com/p/pharo/issues/detail?id=5911 -- Marcus Denker -- http://marcusdenker.de

May 21, 2012