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

Re: [Pharo-project] Trouble loading XML RPC

by StÃ©phane Ducasse

On Jun 4, 2012, at 4:34 PM, Noury Bouraqadi wrote: > Hi GermÃ¡n, > > Thanks for your answer. Indeed, I tried with Pharo 1.4. And had the same issues. > My plan is to port XML RPC to Pharo 2. I'm interested on your work with Zinc. > Where is it available ? > > Can I get write access grant to the repo, so I can upload any improvement I do ? > > What I wanted to do is to cut off everything not XML RPC and complete based on sUnit tests. > BTW, any simple way to load all SUnit tests for all packages ? load: {'Tests'} ? > > I started analyzing the ConfigurationOfxxx classes. > ConfigurationOfXMLSupport includes some references that I would like to have some hints on them (where they are used): ConfigurationOfXMLSupport is a bad example to me it is not good to have all the clients of XML groups. Normally it is much better to have a nice configuration for Opax Sixx Pastell separated. > - Grease > - Opax > - Pastell > - SiXX > - XML-Observable > > Thanx, > Noury > > On 3 juin 2012, at 17:26, garduino wrote: > >> Hi: >> >> Sorry the late answer.... >> >> If you take an 1.4 stock image, and evaluates (as is commented on >> http://code.google.com/p/pharo-xmlrpc/) >> >> Gofer it >> url: 'http://ss3.gemstone.com/ss/XMLRPC'; >> package: 'ConfigurationOfXMLRPC'; >> load. >> >> and then: >> >> >> (ConfigurationOfXMLRPC project version: '1.0-Beta4') load: 'All'. >> >> the whole stuff should load. >> >> I noticed an error: >> >> This package depends on the following classes: >> TranscriptStream >> You must resolve these dependencies before you will be able to load these >> definitions: >> isTranscriptStream >> >> (May be another thing changed in Pharo that I need to know and fix, press >> proceed to load anyway). >> >> But the bad new is that in 1.4 I've some errors on tests, mainly a serious >> one in server that freeze the image, caution. However, the XMLRPC Client >> seems to work. >> >> XMLRPC is always in my to-do list but a project in what I can invest only a >> portion of my limited free time. >> >> The latest new was that I adapted the Client to use with Zinc, but need >> still to make the same thing with the server, then all xmlrpc should install >> and run in a stock image, without need Komanche for example. >> >> With respect to Pharo 2.0 I can't help, not tried yet. >> >> HTH. >> GermÃ¡n. >> >> >> >> >> >> -- >> View this message in context: http://forum.world.st/Trouble-loading-XML-RPC-tp4632653p4633037.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > Noury > -- > http://twitter.com/#!/NouryBouraqadi > http://www.kroobe.com/profile/noury > > > Afin de contribuer au respect de l'environnement, > merci de n'imprimer ce courriel qu'en cas de necessite > > Please consider the environment before you print > > > >

June 4, 2012

Re: [Pharo-project] STDIO on Win

by Ben Coman

Not sure if this is applicable but I bumped into an article [1] which seems to provide a way to get StdIn/StdOut working. The requirement for WSH 5.6 would seems to be covered as [2] is dated 2000 and talks about 5.6 being preinstalled in Whistler, which was development codename for XP - which should cover pretty much everyone. I had got annoyed at Pharo-1.4-one-click.bat leaving a console window open when starting Pharo 1.4, so I re-implemented this as Pharo-1.4-one-click.vbs using Pharo-1.4-one-click.sh as a template. I have attached this to Issue #6020 [3]. [1] http://technet.microsoft.com/en-us/library/ee156605.aspx [2] http://msdn.microsoft.com/en-us/library/ms974613.aspx [3] http://code.google.com/p/pharo/issues/detail?id=6020 Igor Stasenko wrote: > 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) > >

June 4, 2012

[Pharo-project] [update 2.0] #20110

by Esteban Lorenzano

20110 ----- Issue 5977: Rpackage may not handle well method removal in traits http://code.google.com/p/pharo/issues/detail?id=5977 Issue 5997: Classes that implement unsafe equals http://code.google.com/p/pharo/issues/detail?id=5997 Just 3 rpackage tests in yellow now... although this is not the end of history, just the beginning, we are getting closer :)

June 4, 2012

Re: [Pharo-project] Next step in cleaning DataStream

by Damien Cassou

On Mon, Jun 4, 2012 at 6:09 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > I think it is a good proposal. Then it can be in separate package or as part > of MC package. I would put DataStream and its friends within the monticello package, and prepend MC to their names. Then, you can clean the resulting classes if you want to. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 4, 2012

Re: [Pharo-project] Next step in cleaning DataStream

by Pavel Krivanek

4. 6. 2012 v 17:58, Mariano Martinez Peck <marianopeck(a)gmail.com>: > So, so far we have removed SmartRefStream, deprecated ReferenceStream and integrated Fuel. The ONLY remaining user for DataStream is Monticello. We do not want to replace that yet because Fuel may still change the format and we do not want to break monticello versions. But, my question is now...should we clean DataStream and assume its only usage will be the definitions of Monticello? becuase I true, I think we may be able to remove DiskProxy and all its users, togethet with lots of methods like #objectForDataStream: > > what do you think? I think it is a good proposal. Then it can be in separate package or as part of MC package. -- Pavel > > -- > Mariano > http://marianopeck.wordpress.com >

June 4, 2012

[Pharo-project] Next step in cleaning DataStream

by Mariano Martinez Peck

So, so far we have removed SmartRefStream, deprecated ReferenceStream and integrated Fuel. The ONLY remaining user for DataStream is Monticello. We do not want to replace that yet because Fuel may still change the format and we do not want to break monticello versions. But, my question is now...should we clean DataStream and assume its only usage will be the definitions of Monticello? becuase I true, I think we may be able to remove DiskProxy and all its users, togethet with lots of methods like #objectForDataStream: what do you think? -- Mariano http://marianopeck.wordpress.com

June 4, 2012

Re: [Pharo-project] What i would like to have instead of progress bar

by Chris Muller

I know I'm late to the discussion, but I thought I'd share features of my own design of MaClientProcess, which has been part of the Maui framework for Squeak since 2004, how it handles progress. It is based on the ultimate progress-bar handling I did in VisualAge and published in 1997: - The ClientProcess runs in the background, of course. - It's UI can be placed anywhere on the desktop, or minimized. - Shows time elapsed and estimated time remaining. - Shows units processed as a fraction of total units. - Allows descriptions of sub-tasks being worked on to be displayed. - Doesn't appear at all unless the task takes more than 5 seconds to complete, that way the system is not presenting progress bar and then immediately removing it. - Allows the user to PAUSE or change the priority of the Process -- generically without client code knowing anything about that. - No nesting. - UI updates based on a time-interval rather than client processing so that performance is NOT affected. On Thu, May 31, 2012 at 6:58 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > If you would ask me (yeah nobody asking me, by i will tell anyways ;) ) > how the indication of a progress of some process should look like, > here's my potential answer: > > > - a tiny one line in a corner of desktop (instead of huge banner > centered in window, > Â sticking on top of everything and obscuring the view) > - not blocking user input > - no stupid nesting.. i don't care what happens inside of something > else happens.. > if it is really necessary, i would just replace the title of a task > with it's subtask title while it performing. > this is just about first rule: it has to be a single line, not a bunch > of lines stocking one over another.. > i think this is abuse. > > most of the times, i just need a notion of progress of a whole thing, > not progress of it's subthings > (if user really wants, he can hover the mouse over progress line to > see the details, but by default > it should take minimal space on the screen). > > > > -- > Best regards, > Igor Stasenko. >

June 4, 2012

Re: [Pharo-project] Trouble loading XML RPC

by Noury Bouraqadi

Hi GermÃ¡n, Thanks for your answer. Indeed, I tried with Pharo 1.4. And had the same issues. My plan is to port XML RPC to Pharo 2. I'm interested on your work with Zinc. Where is it available ? Can I get write access grant to the repo, so I can upload any improvement I do ? What I wanted to do is to cut off everything not XML RPC and complete based on sUnit tests. BTW, any simple way to load all SUnit tests for all packages ? I started analyzing the ConfigurationOfxxx classes. ConfigurationOfXMLSupport includes some references that I would like to have some hints on them (where they are used): - Grease - Opax - Pastell - SiXX - XML-Observable Thanx, Noury On 3 juin 2012, at 17:26, garduino wrote: > Hi: > > Sorry the late answer.... > > If you take an 1.4 stock image, and evaluates (as is commented on > http://code.google.com/p/pharo-xmlrpc/) > > Gofer it > url: 'http://ss3.gemstone.com/ss/XMLRPC'; > package: 'ConfigurationOfXMLRPC'; > load. > > and then: > > > (ConfigurationOfXMLRPC project version: '1.0-Beta4') load: 'All'. > > the whole stuff should load. > > I noticed an error: > > This package depends on the following classes: > TranscriptStream > You must resolve these dependencies before you will be able to load these > definitions: > isTranscriptStream > > (May be another thing changed in Pharo that I need to know and fix, press > proceed to load anyway). > > But the bad new is that in 1.4 I've some errors on tests, mainly a serious > one in server that freeze the image, caution. However, the XMLRPC Client > seems to work. > > XMLRPC is always in my to-do list but a project in what I can invest only a > portion of my limited free time. > > The latest new was that I adapted the Client to use with Zinc, but need > still to make the same thing with the server, then all xmlrpc should install > and run in a stock image, without need Komanche for example. > > With respect to Pharo 2.0 I can't help, not tried yet. > > HTH. > GermÃ¡n. > > > > > > -- > View this message in context: http://forum.world.st/Trouble-loading-XML-RPC-tp4632653p4633037.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > Noury -- http://twitter.com/#!/NouryBouraqadi http://www.kroobe.com/profile/noury Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite Please consider the environment before you print

June 4, 2012

Re: [Pharo-project] [ConcreteTypeInference] news.

by Santiago Bragagnolo

Thanks :3, i working a lot. ea, ahora me suscribo!. 2012/6/4 Edgar J. De Cleene <edgardec2005(a)gmail.com> > > > > On 6/3/12 10:31 PM, "Santiago Bragagnolo" <santiagobragagnolo(a)gmail.com> > wrote: > > Hi all! > > > I'm announcing four new posts on the blog, > > Concrete types - A little brief about concrete types to understand the > mechanisms > *http://concretetypeinference.blogspot.com.ar/2012/06/concrete-types.html > * > About mechanisms part 1 - talking about problems getting green the tests > :). This revision is about contexts of block evaluation > * > http://concretetypeinference.blogspot.com.ar/2012/06/about-mechanisms-part-… > * > About mechanisms part 2 - This revision is about a pretty weird scenario > * > http://concretetypeinference.blogspot.com.ar/2012/06/about-mechanisms-part-… > * > Metacello configuration - nothing to add to the title. > * > http://concretetypeinference.blogspot.com.ar/2012/06/metacello-concretetype… > * > > Good week. > > I enjoying your blog and your work. > Please continue. > > Y me gustarÃa te unas a http://ar.groups.yahoo.com/group/squeakRos/ > > Edgar >

June 4, 2012

Re: [Pharo-project] Log fwk

by Santiago Bragagnolo

Yeah. i was waiting for the integration of TAnnouncer to announcements, but well, i added just now a copy with other name. In other words, theres no more Tannouncer bug :) Thanks for the feedback! 2012/6/4 Edgar J. De Cleene <edgardec2005(a)gmail.com> > > > > On 6/3/12 8:11 PM, "Santiago Bragagnolo" <santiagobragagnolo(a)gmail.com> > wrote: > > I have added a metacello configuration for the project: > There's only one version, so bleeding edge. > > Gofer new > squeaksource3: 'PaulLePoulpe'; > package: 'ConfigurationOfPaulLePoulpe'; > load. > > ConfigurationOfPaulLePoulpe project bleedingEdge load > > > > In both Pharo 1.4 and Pharo 2.0 updated I get this odd: > > Gofer new > Argument expected ->squeaksource3: 'PaulLePoulpe'; > package: 'ConfigurationOfPaulLePoulpe'; > load. > > When I do by hand, start to load until I got the attached error. > > Edgar >

June 4, 2012