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

[Pharo-project] [update 2.0] #20085

by Esteban Lorenzano

20085 ----- Issue 5929: Some Unix shortcuts needs to be fixed http://code.google.com/p/pharo/issues/detail?id=5929

May 21, 2012

[Pharo-project] SystemNavigationTest>>setUp looks quite strange to me

by StÃ©phane Ducasse

Hi guillermo I saw that you modified setUp super setUp. oldMonticelloAnnouncer := SystemAnnouncer privateAnnouncer. SystemAnnouncer instVarNamed: 'privateAnnouncer' put: nil. navigator := self createSystemNavigationToTest. classFactory := self createClassFactory. Now I would like to understand why? Especially because privateAnnouncer should not be used and touched. SystemAnnouncer privateAnnouncer returns an announcer that should only be used by internal (not tools). BTW the teardown looks wrong to me. Stef

May 21, 2012

Re: [Pharo-project] SciSmalltalk on twitter !

by Serge Stinckwich

On Mon, May 21, 2012 at 10:53 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > 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. Tweets are for sharing progress with people that don't want to follow the project. If you want to follow the project more closely, you can have a look to the Wiki and issues here: https://github.com/SergeStinckwich/SciSmalltalk Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

May 21, 2012

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

by chadwick

more detail: after I do GLTTRenderingDemo new openInWorld, I tried dragging a window around in a circle so as to get a feel for what the CPU is doing. The image pauses for increasingly longer times, making the UI unresponsive during this time, eventually locking up entirely.

May 21, 2012

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