- Pharo-dev - lists.pharo.org

Re: [Pharo-project] SciSmalltalk on twitter !

by Yanni Chiu

On 20/05/12 4:54 PM, Edgar J. De Cleene wrote: > > On 5/20/12 1:01 PM, "Serge Stinckwich"<serge.stinckwich(a)gmail.com> wrote: > >> I invite all the students that are working on Smalltalk #gsoc to >> publish progress of their work on twitter also. > > +1 -1 What's wrong with weekly (or milestone) updates posted someplace. I'm interested in following along, but not hour by hour. Also, whenever I've tried to find old tweets, I would get something like: search results for old tweets not available - which meant I had to follow continuously. And another thing, trying to track stuff on twitter is like trying to get a drink from a fire hose. Despite culling and ignoring, it got so out of hand, I just switched it off. Maybe I'm doing something wrong.

May 21, 2012

Re: [Pharo-project] STDIO on Win

by Igor Stasenko

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. > Â - use GetStdHandle() for reliable results. > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

May 21, 2012

Re: [Pharo-project] STDIO on Win

by Igor Stasenko

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 - use GetStdHandle() for reliable results. -- Best regards, Igor Stasenko.

May 21, 2012

Re: [Pharo-project] Morpheas , bringing Morphic to Opengl (3d GUIs)

by chadwick

On Sat, May 19, 2012 at 2:35 AM, Javier PimÃ¡s <elpochodelagente(a)gmail.com>wrote: > Well, two things should happen: a native window should be opened which > shows nothing (context creation should be fixed to not create it), and also > a morph should be opened in world, rendering some text through opengl. > > Does the window get opened? does the image freeze? > no the image does not freeze initially, but it does after a few minutes. It runs slowly though. No other windows open and there is no error in the terminal.

May 21, 2012

Re: [Pharo-project] About process startups

by Guillermo Polito

On Thu, May 17, 2012 at 3:22 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Do you want something like this? > > Process subclass: #PermanentSystemProcess > > PermanentSystemProcess subclass: #DelayProcess > PermanentSystemProcess subclass: #WeakFinalizationProcess > PermanentSystemProcess subclass: #UIProcess > PermanentSystemProcess subclass: #IdleProcess > ... > Hmm, really don't know what I want. Just know I do not like chaos some times :). I was asking if there is a reason for not doing something like you describe for example :P. Anyway. These permanent system processes should be documented somewhere, and the ability to find them, turn them on/off and install/uninstall them is kind of desirable for the bootstrap for example... And if I have to do it this way: (Process allInstances detect: [ :p | p name = 'blabla' ]) terminate (WeakArray classPool at: #FinalizationProcess) suspend seems me more like a hack than a real solution. Guille > > On 17 May 2012 13:44, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > > On May 16, 2012, at 10:59 PM, Guillermo Polito wrote: > > > >> > >> On Wed, May 16, 2012 at 8:59 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> I do not really like the class idea. > >> > >> why not? Maybe it does not apply for every process, but for some of > them. > > > > Because I'm not sure that I like having one class per object. > > > >> Morphic UI process could belong to MorphicUIManager, but, does the > finalization process belong to weak array? why not to weak registry or weak > ordered collection then? :S > >> > >> May be having a convention + a pragma for the methods is good. > >> > >> Stef > >> > >> On May 16, 2012, at 3:27 PM, Guillermo Polito wrote: > >> > >> > I'm playing with the process initialization for the bootstrap, and > some things come to my mind. > >> > > >> > There are some classes that startup processes on the class side > initialize, like > >> > > >> > WeakArray -> Finalization process > >> > Delay -> Timer event loop > >> > > >> > What it is not clear to me is if those processes should be installed > when the class is initialized, or when it is startupped for the first time. > Also, I can't stop thinking that the processes in the image are all spread > and not clear. If I want to know where the processes are defined, it's > kind of a mess. > >> > > >> > Is having specialized objects for our processes undesired by some > reason I can't see? I'd like to have objects like > >> > > >> > MorphicUIProcess > >> > FinalizationProcess > >> > TimeEventProcess > >> > ... > >> > and so on > >> > > >> > Guille > >> > >> > >> > > > > > > > > -- > Best regards, > Igor Stasenko. > >

May 21, 2012

Re: [Pharo-project] STDIO on Win

by Eliot Miranda

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. > > *** > One of the common misconceptions surrounding Win32 programming is that > you must decide early in the design process whether your application > will be a console or GUI application. In reality, console applications > can create windows and have a message loop just like a GUI application > (see "Adding Graphics to Console Applications" by Michael Covington, > Visual Developer, June/July 1997). Alternatively, graphical > applications can create and use a console. Although Win32 provides > functions for communicating with a console, they are a little clumsy > to use and require parameters that are unnecessary for simple text > I/O. This article shows how to use standard C/C++ I/O with consoles, > and how to work around specific problems in the Visual C++ I/O > library. > *** > http://dslweb.nwnexus.com/~ast/dload/guicon.htm > > > -- > > best, > > Eliot > > > > > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

May 21, 2012

Re: [Pharo-project] STDIO on Win

by Igor Stasenko

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 :) *** One of the common misconceptions surrounding Win32 programming is that you must decide early in the design process whether your application will be a console or GUI application. In reality, console applications can create windows and have a message loop just like a GUI application (see "Adding Graphics to Console Applications" by Michael Covington, Visual Developer, June/July 1997). Alternatively, graphical applications can create and use a console. Although Win32 provides functions for communicating with a console, they are a little clumsy to use and require parameters that are unnecessary for simple text I/O. This article shows how to use standard C/C++ I/O with consoles, and how to work around specific problems in the Visual C++ I/O library. *** http://dslweb.nwnexus.com/~ast/dload/guicon.htm > -- > best, > Eliot > -- Best regards, Igor Stasenko.

May 20, 2012

Re: [Pharo-project] SciSmalltalk on twitter !

by Edgar J. De Cleene

On 5/20/12 1:01 PM, "Serge Stinckwich" <serge.stinckwich(a)gmail.com> wrote: > I invite all the students that are working on Smalltalk #gsoc to > publish progress of their work on twitter also. +1 Edgar

May 20, 2012

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

by Hilaire Fernandes

Is the memory object corrupted in Pharo 1.4? And explain the problem I have in some situation with DrGeo on XO-1 256MB without swap. http://lists.squeak.org/pipermail/vm-dev/2012-May/010652.html Hilaire Le 20/05/2012 13:57, Hilaire Fernandes a Ã©crit : > With Pharo 1.4 (but not with Pharo 1.3) we have a problem leading to the > crash of DrGeo (based on Pharo 1.4) on low memory machine. > > It is clearly a problem related to Pharo 1.4 > > Any idea why ? > > Hilaire > > > -------- Original Message -------- > Subject: Re: [Sugar-devel] Dr.Geo on XO 1 > Date: Sun, 20 May 2012 13:46:01 +0200 > From: Bert Freudenberg <bert(a)freudenbergs.de> > To: Sascha Silbe <silbe(a)activitycentral.com> > CC: Ariel Calzada <ariel.calzada(a)gmail.com>, Hilaire Fernandes > <hilaire.fernandes(a)edu.ge.ch>, Sugar Devel > <sugar-devel(a)lists.sugarlabs.org>, Rafael Ortiz > <rafael(a)activitycentral.com> > > > > On 20.05.2012, at 11:00, Sascha Silbe wrote: > >> Bert Freudenberg <bert(a)freudenbergs.de> writes: >> >>> Nope, that was not it. I compiled with -mtune=geode, makes no >>> difference. >> >> Make sure to set -march=<architecture> to something appropriate. -march >> tells gcc what instructions it can use (so anything that doesn't support >> these instructions will fail to run the resulting executable), whereas >> -mtune only tells it to optimise for a certain processor type (but the >> executable will continue to run on other processors as long as they >> support the instruction set specified by -march). > > I actually had used "-march=pentiumpro -mtune=geode" as recommended here: > > http://wiki.laptop.org/go/Geode_LX > > and even with an additional -O0 it still crashes. > >> In gdb I see it's segfaulting inside the GC logic. It's really >>> puzzling this only happens on the XO-1 ... >> >> You could try booting an XO-1.5 with mem=256M (append that to boot-file >> in /bootpart/boot/olpc.fth) to simulate the memory pressure of an XO-1. > > > YES! That reproduces the crash on XO-1.5. Good thinking! :) > > 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 ... > > - Bert - > > > > >

May 20, 2012

Re: [Pharo-project] STDIO on Win

by Eliot Miranda

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". -- best, Eliot

May 20, 2012