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

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

[Pharo-project] [update 1.4] #14443

by Marcus Denker

14443 ----- Issue 5833: More robust allSuperclassesIncluding: http://code.google.com/p/pharo/issues/detail?id=5833 -- Marcus Denker -- http://marcusdenker.de

May 21, 2012

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

by Marcus Denker

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

[Pharo-project] [update 1.3] #13329

by Marcus Denker

13329 ----- Issue 4617: More error tolerant startup http://code.google.com/p/pharo/issues/detail?id=4617 -- Marcus Denker -- http://marcusdenker.de

May 21, 2012

[Pharo-project] Fwd: CFP IWST'2012

by Marcus Denker

---------- Forwarded message ---------- From: LoÃ¯c Lagadec <loic.lagadec(a)univ-brest.fr> Subject: [Esug-list] CFP IWST'2012 DearÂ colleagues & Friends, We apologize for multiple reception of this announcement. The International Workshop on Smalltalk Technologies, is a European Smalltalk User Group (ESUG) Conference joint event, that focuses on research activities - namely academic creative work undertaken on smalltalk use, and more generally on object technologies. IWST was launched in 2009, in Brest, during the 17th ESUG Conference. The second edition took place in Barcelona, and the third edition was held in 2011 at the heart of historic Edinburgh. Next edition will be in Gent, Begium this summer (28th of august). ESUG gathers groups of professionals and hobbyists who share an interest in the Smalltalk programming languages and related technologies. The goal of the workshop is to create a forum around advances or experience in Smalltalk. IWST contributes to triggering discussions and exchanges of ideas. As always, we make a point to have a very constructive paper review process that aims to provide in-depth comments and suggestions to all of them (no one-liners!) This makes it ideal to disseminate new research directions, and is a good venue for early stage PhD students to receive feedback on their work. In addition, we intent to invite best papers to a journal special issue as we did last year. Looking forward to your submissions, and to meeting you in Gent! Best regards, LoÃ¯c Lagadec & Alain Plantec Co-chairs of IWST International Workshop on Smalltalk Technologies 2012 August 28th, 2012 Gent, Belgium. ESUG 2012 Smalltalk joint event Important dates Submission deadline: June 15, 2012 Notification deadline: July 15, 2012 All accepted papers will be published in ACM DL, and the authors of the best papers will be invited to submit an extended version to a journal special issue (To Be Confirmed). Goals and scopes The goals of the workshop is to create a forum around advances or experience in Smalltalk and to trigger discussions and exchanges of ideas. Participants are invited to submit research articles. We will not enforce any length restriction. However we expect papers of two kinds: Short position papers describing emerging ideas. Long research papers with deeper description of experiments and of research results. Topics We welcome contributions on all aspects, theoretical as well as practical, of Smalltalk related topics such as: Aspect-oriented programming, Design patterns, Experience reports, Frameworks, Implementation, new dialects or languages implemented in Smalltalk, Interaction with other languages, Meta-programming and Meta-modeling, Tools Links home page: http://www.esug.org/wiki/pier/Conferences/2012/International-Workshop---IWS… submission: http://www.easychair.org/conferences/?conf=iwst2012 Publication Both submissions and final papers must be prepared using the ACM SIGPLAN 10 point format. Templates for Word and LaTeX are available at http://www.acm.org/sigs/sigplan/authorInformation.htm. This site also contains links to useful informations on how to write effective submissions. Program chairs LoÃ¯c Lagadec and Alain Plantec (LabSticc CACS/CNRS, University of Brest, France) Program committee Gabriela ArevaloÂ Â Â Universidad Nacional de Quilmes, Argentina Alexandre BergelÂ Â Â University of Chile Andrew P. BlackÂ Â Â Portland State University, US Marcus DenkerÂ Â Â Rmod, INRIA Lille - Nord Europe, France Luc FabresseÂ Â Â Ecole des Mines de Douai, France, Tudor GirbaÂ Â Â CompuGroup Medical Schweiz, Switzerland Andy KellensÂ Â Â Software Languages Lab, Vrije Universiteit Brussel, Belgium MickaÃ«l KerboeufÂ Â Â LabSticc, University of Brest, France Jannik LavalÂ Â Â LaBRI, University of Bordeaux, France Mariano Martinez PeckÂ Â Â Ecole des Mines de Douai, France, Lukas RenggliÂ Â Â Google, Switzerland Jorge RessiaÂ Â Â Software Composition Group, University of Bern, Switzerland Bastian SteinertÂ Â Â HPI, Software Architecture Group, Germany Hernan WilkinsonÂ Â Â 10Pines, IT consultancy, Buenos Aires, Argentina Roel WuytsÂ Â Â IMEC Leuven, Belgium _______________________________________________ Esug-list mailing list Esug-list(a)lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org -- -- Marcus DenkerÂ --Â denker(a)acm.org http://www.marcusdenker.de

May 21, 2012

Re: [Pharo-project] Browsing long methods

by Fernando Olivero

yes, you are right, we should improve Morphic, and Gaucho should be released soon! Regarding cleaning up PluggableTextMorph, i think a better solution would be to rewrite it, i've coded NewTextMorph once (a minimal version). Instead of trying to fix an complicated Morph. On Mon, May 21, 2012 at 2:50 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yes but if we do not improve the system and gaucho is not usable by other than you > then at the end we got nothing so the solution is > Â Â Â Â to improve the system > Â Â Â Â and eventually be ready to switch to something better but not before :) > > Stef > >> PluggableTextMorph and friends Â are a mess, i've tried to clean it up >> once and found it to be really hard. >> >> I will be showing the support for text in Shapes ( the UI framework >> used by Gaucho), which lays Â out text using Pango, and renderers it >> using Athens (with a Cairo backend). Simple and yet powerful, thanks >> to Pango. >> >> Fernando >> >> >> On Mon, May 21, 2012 at 12:42 PM, Guillermo Polito >> <guillermopolito(a)gmail.com> wrote: >>> Nice, the paragraph is calculated about 7~8 times in a pluggable text morph (depending on the user). >>> >>> And since the composition of a paragraph for a long method takes long (some minutes), it takes 7 times to render it (I've never was able to wait for it. Â I always lose my patience before). >>> >>> Guille >>> >>> On Mon, May 21, 2012 at 11:41 AM, Guillermo Polito <guillermopolito(a)gmail.com<mailto:guillermopolito@gmail.com>> wrote: >>> Browsing a long method (lets say, of ~270KB of sourcecode) just hangs the image. >>> >>> Interrupting doesn't even give me control over my image again. Â It does no open a debugger, but info is printed in stdout, so I assume that my UIProcess died, but the event fetcher is still alive... >>> >>> One of the processes that get interrupted prints: >>> >>> SmallIdentityDictionary(SmallDictionary)>>at:ifAbsent: >>> MorphExtension>>valueOfProperty:ifAbsent: >>> MorphExtension>>valueOfProperty: >>> ScrollBar(Morph)>>valueOfProperty: >>> ScrollBar(Morph)>>theme >>> ScrollBar>>normalThumbFillStyle >>> ScrollBar>>adoptGradientColor: >>> ScrollBar>>sliderColor: >>> ScrollBar>>adoptPaneColor: >>> PluggableMultiColumnListMorph(Morph)>>adoptPaneColor: in Block: [:m | m adoptPaneColor: paneColor] >>> >>> So I just changed #adoptPaneColor: in ScrollBar to do nothing, and I am able to interrupt again. So it makes me think here it is where the UIProcess gets killed... >>> >>> Now, for the browser stuff, it seems that TextComposer>>#composeAllLines never finishes. Â I'm still investigating, but any clue is helpful :). >>> >>> Guille >>> >> >

May 21, 2012

Re: [Pharo-project] Place to sleep Lille

by Stephan Eggermont

Hi Stef, Thanks. The Formule 1 still had a room (others didn't). What's the place to meet on wednesday evening for a beer & talk? I'll arrive 21.00 or so. Stephan

May 21, 2012