September 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] feedback on CLFramework

by StÃ©phane Ducasse

Hi nullPointer here are some feedback on your work that is really important for us. Use Smalltalk way of formatting code. ========================== btn -> button please use normal smalltalk conventions. inClassSideBoolean ifTrue: [ aClass class compile: aStringCodeSource classified: (aSymbolCategoryName asString) notifying: nil. ] ifFalse: [ aClass compile: aStringCodeSource classified: (aSymbolCategoryName asString) notifying: nil. ]. or inClassSideBoolean ifTrue: [ aClass class compile: aStringCodeSource classified: (aSymbolCategoryName asString) notifying: nil. ] ifFalse: [ aClass compile: aStringCodeSource classified: (aSymbolCategoryName asString) notifying: nil. ]. getFiles: aStringPathOfDirectory | aFileDirectory fullPathOfFile aCollection | aFileDirectory := CLFileDirectory on: aStringPathOfDirectory. aCollection := Bag new. aFileDirectory fileNames do: [ :nameOfFile | fullPathOfFile := aFileDirectory fullPathFor: nameOfFile. aCollection add: fullPathOfFile. ]. ^aCollection. Don't use space everywhere is not smalltalk getFiles: aStringPathOfDirectory | aFileDirectory fullPathOfFile aCollection | aFileDirectory := CLFileDirectory on: aStringPathOfDirectory. aCollection := Bag new. aFileDirectory fileNames do: [:nameOfFile | fullPathOfFile := aFileDirectory fullPathFor: nameOfFile. aCollection add: fullPathOfFile]. ^aCollection. If you give me access I can reformat everything. Add some comments ========================== In the examples category there is no class comments so I have no idea about what I'm reading. There is not one single class comment: please add some of them. So far I could not find how to use it Do not refer to your class inside itself ========================== CLCompiler>>createMessageInClass: aClass withCodeSource: aStringCodeSource inProtocol: aSymbolCategoryName CLCompiler createMessageInClass: aClass withCodeSource: aStringCodeSource inProtocol: aSymbolCategoryName inClassSide: false. -> CLCompiler>>createMessageInClass: aClass withCodeSource: aStringCodeSource inProtocol: aSymbolCategoryName self createMessageInClass: aClass withCodeSource: aStringCodeSource inProtocol: aSymbolCategoryName inClassSide: false. Nice to see that you use traits :) ========================= Keep working. I still believe that a windowSpec based on a literal array is better than a byte array. Stef

Sept. 26, 2009

Re: [Pharo-project] OSProcess question

by StÃ©phane Ducasse

check the preferences you can also ignore them or get atrace in the transcript On Sep 26, 2009, at 5:04 PM, Schwab,Wilhelm K wrote: > Dave, > > I just tried command shell; are you _sure_ it is possible to proceed > past the errors? It looks badly broken from here. I can't say I'm > happy with the way Pharo brings things to a halt over deprecated > methods; yes, it gets attention before things go away in future > release, but there are times when I would like to gag it and just > get some work done. > > I still do not see the tests. Are you saying that they should have > been installed with OSProess itself? If there are separate packages > on ss, I don't see them either. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of David T. Lewis > Sent: Saturday, September 26, 2009 9:23 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] OSProcess question > > On Fri, Sep 25, 2009 at 11:48:22PM -0400, Schwab,Wilhelm K wrote: >> I see various ways to run something, none of which are quite what I >> want. The objective is to run openssl in a particular directory. >> I have no need to make this portable (unless you mean running on >> all of Ubuntu, Debian, Slackware, etc. <g>), so >> #forkAndExec:...workingDirectory: would almost be ok, **but**, I >> need to wait around for the result. In truth, there are a few >> things that have to happen in sequence; perhaps I could simply >> write multiple lines to the command string. >> > > You should install CommandShell, which is a companion to OSProcess. > Look at the class side methods in CommandShell and PipeableOSProcess > for examples, also look at the unit tests. > > CommandShell has an MVC user interface as well as Morphic, so you > will have to proceed through the errors when loading on Pharo. > >> Still, in the interest of idealism, it would be nice to run the >> commands on other than the Pharo main thread (no sense diving into >> something that might not return[*]), and to know when the work is >> done, and to get the different steps to happen in sequence. >> > > PipeableOSProcess uses non-blocking I/O and event driven input. > There should be no problem with blocking if you use this. If you use > the lower-level classes in OSProcess, you need to handle issues like > this yourself (also beware of "pipe handle leaks" from failing to > close file descriptors if you are handling this yourself). > >> There was mention of tests for OSProcess (which might provide >> clues), but I have not been able to find them. Any hints? > > Tests for OSProcess and CommandShell are in the SqueakSource > projects. The package names are Tests-OSProcess and Tests- > CommandShell. > > Dave > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 26, 2009

Re: [Pharo-project] ClosureTests remove expected failures

by StÃ©phane Ducasse

integrated. :) stef On Sep 26, 2009, at 7:27 PM, StÃ©phane Ducasse wrote: > yes > > On Sep 26, 2009, at 6:22 PM, Michael Roberts wrote: > >> Compiler-MikeRoberts.132 in Inbox >> >> Remove unexpected failures since the tests now pass with Eliot's >> latest batch of closure fixes. >> >> thanks, >> Mike >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 26, 2009

[Pharo-project] [update] #10460

by StÃ©phane Ducasse

10460 ----- - Issue 1246: MethodPropertiesTests expected failures - Issue 1247: ClosureTests remove expectedFailures - Issue 1242: MessageNotUnderstood: ProjectViewMorph class>>serviceOpenProjectFromFile - Issue 1248: Orange Transcript - Issue 1240: Mantis 1035 : resizing a polygonMorph contained in a proportional layout is weird - Issue 1232: Delay bug a further step towards 1.0 stef

Sept. 26, 2009

Re: [Pharo-project] OSProcess question

by David T. Lewis

On Sat, Sep 26, 2009 at 11:04:37AM -0400, Schwab,Wilhelm K wrote: > Dave, > > I just tried command shell; are you _sure_ it is possible to proceed past the errors? No, I had not checked on the most recent Pharo. So I just downloaded a Pharo image to try it. You can proceed through the warnings about missing MVC stuff. And when you get to the end of the install, the CommandShell class>>initialize will put you into a debugger. Comment out the last line where it is trying to open a CommandShell window, then proceed. This should get you through the installation. > It looks badly broken from here. It looks pretty bad from here also. The Morphic UI no longer works (it was working the last time I looked at Pharo, but not now). Some AioEventHandlerTestCase tests are now failing due to something different in Socket. Some of the CommandShellTestCase tests get hung up when doing very complex command pipelines (i.e. lots of Process coordination). But if you limit yourself to running simple commands and do not use the CommandShell user interface, it should still do what you need. > I can't say I'm happy with the way Pharo brings things to a halt over deprecated methods; yes, it gets attention before things go away in future release, but there are times when I would like to gag it and just get some work done. > Mea culpa, I just fixed the deprecated method issue in CommandShell, so if you load the latest version now this problem should be gone. > I still do not see the tests. Are you saying that they should have been installed with OSProess itself? If there are separate packages on ss, I don't see them either. > Open this MC repository: MCHttpRepository location: 'http://www.squeaksource.com/OSProcess' user: '' password: '' Then load the latest versions of both of these packags: OSProcess Tests-OSProcess Open this MC repository: MCHttpRepository location: 'http://www.squeaksource.com/CommandShell' user: '' password: '' And load the latest versions of both these packages: CommandShell Tests-CommandShell HTH, Dave

Sept. 26, 2009

Re: [Pharo-project] CAnalyer

by StÃ©phane Ducasse

this is just a wrapper around scrML to create C entities in Moose stef On Sep 26, 2009, at 4:36 PM, Schwab,Wilhelm K wrote: > The CAnalyzer entry on Squeak Source says to install it like this: > > ScriptLoader new installer ss project: 'CAnalyzer'; install: > 'CAnalyzerLoader'. ScriptLoader perform: #loadCAnalyzer. > > But that blows up for want of what looks like parts of MOOSE. I > have the new beta at least attempting to install MOOSE; so far, it > ended in a frozen image, but I'm retrying it. Is there a better > way to load CAnalyzer? > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr > ] On Behalf Of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] > Sent: Saturday, September 26, 2009 9:42 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] CAnalyer > > Sig, > > Interesting. I looked at swig and decided that I would have a > better chance of success with pattern matching, especially since > some of the "code" I want to analyze is barely pseudo code (but > still full of valuable information). I ended up with a bit of a > mess in Dolphin, but it strangely manages to work; for Pharo, I > planned to clean it up, got as far as noticing the regex package, > and saw CAnalyzer. > > That is a long way around saying that I am not eager to tear back > into swig, but your argument about the working preprocessor and > parser is well taken and I would like to see what you did. I should > at least look at CAnalyzer and then either switch to it or begin > moving my unit tests and higher-level recognizers to Pharo. Leaving > the whole thing in Dolphin is an option too, but the code really > needs some cleaning, so the port would do it and me some good. I > will be glad to look over your work and maybe put swig back into > consideration. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of Igor Stasenko > Sent: Saturday, September 26, 2009 12:53 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] CAnalyer > > 2009/9/26 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Sig, >> >> Is it something you have made available? One snag in my world is >> that the "code" is not always something that can be compiled. >> However, for GSL and other libraries of interest, the code is >> valid, if not full of macro-based annoyances and other distractions. >> > the code i written is the module to SWIG. > The project what i developed once is to write a smalltalk > interpreter by own, and the aim was to use it as a scripting engine > for C++ projects. > My experiments stopped shortly after i understood that my > interpreter implementation having some flaws and i need to spend > much time to rewrite everything :) But, along the way, i started > making bindings to Ogre 3D engine > (http://www.ogre3d.org/) > and my SWIG-based binding code generator were able to reflect C++ > classes in my own smalltalk, including being able to call > constructors/destructors, methods and directly access the fields by > using auto-generated primives. > If you wanna to get deeper into that, i can send you the sources and > examples. > With a little effort, the code generation could be easily changed to > satisfy the FFI/Alien demands, then you will be able to bind any C > library with Squeak VM. > >> Bill >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >> Igor >> Stasenko >> Sent: Friday, September 25, 2009 11:03 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] CAnalyer >> >> 2009/9/26 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >>> I was digging around on Squeak Source for OSProcess and friends, >>> and ran across CAnalyzer. Are there any papers on it? How robust >>> is it? What does it extract from C code? For example, might one >>> put the GSL (www.gnu.org/software/gsl) header files into it, pull >>> out all of the structure definitions and function prototypes, and >>> generate LOTS of FFI code to make a wrapper? Just a thought... >>> >> >> I having a modified version of SWIG, which can parse C++ files, >> including classes and nested classes, to produce smalltalk code >> wrappers. >> >> Reproducing the SWIG in smalltalk would be very time consuming. >> But it would be cool to have a C/C++ parser implementation. >> >> SWIG is not only parsing, its also doing macro preprocessing, so its >> can't be fooled with macros :) >> >>> Bill >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 26, 2009

Re: [Pharo-project] ClosureTests remove expected failures

by StÃ©phane Ducasse

yes On Sep 26, 2009, at 6:22 PM, Michael Roberts wrote: > Compiler-MikeRoberts.132 in Inbox > > Remove unexpected failures since the tests now pass with Eliot's > latest batch of closure fixes. > > thanks, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 26, 2009

Re: [Pharo-project] Compiler tests naming

by StÃ©phane Ducasse

yes On Sep 26, 2009, at 6:16 PM, Michael Roberts wrote: > I've noticed we've got two sets of compiler tests. One category part > of the compiler and one part of its own tests package. Assume we want > to just the tests all into their own package? > > thanks, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 26, 2009

[Pharo-project] ClosureTests remove expected failures

by Michael Roberts

Compiler-MikeRoberts.132 in Inbox Remove unexpected failures since the tests now pass with Eliot's latest batch of closure fixes. thanks, Mike

Sept. 26, 2009

[Pharo-project] Compiler tests naming

by Michael Roberts

I've noticed we've got two sets of compiler tests. One category part of the compiler and one part of its own tests package. Assume we want to just the tests all into their own package? thanks, Mike

Sept. 26, 2009