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

[Pharo-project] Fixing the StackInterpreterSimulator for Pharo 1.4

by Stefan Marr

Hi: The attached change set fixes bit rot in the StackInterpreterSimulator and related classes. Here a brief summary: - VMClass>>#doOrDefer: now uses ProcessBrowser>>#isUIProcess: instead of Project - it replaces the use of #asDisplayText with StringMorph>>#contents:. - use of ThreadStream>>#on: is replaced with ThreadSafeTranscript>>#new - Utilities is replaced by UIManager>>#default - and #primitiveGetAttribute now uses the non-depricated `Smalltalk vm getSystemAttribute: attr` For the last change, I wonder whether that's going to work, because that code is going to be translated to C, right? Is anyone interest in these changes? Should I also fix the other simulators? With them, I can load a Pharo 1.2.1 image in the simulator, I wasn't patient enough to wait for a 1.4 image to complete loading. | sim | InterpreterStackPage initialize. sim := StackInterpreterSimulator new. sim openOn: '/.../Downloads/Pharo-1.2.1-11.04.03/Pharo-1.2.1.image'. sim openAsMorph. [ sim run ] fork. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Nov. 6, 2012

Re: [Pharo-project] Pharo 2.0 and Metacello preview

by Igor Stasenko

On 6 November 2012 16:00, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 6 November 2012 18:07, Igor Stasenko <siguctua(a)gmail.com> wrote: >> Basically, what is needed is: >> VMs with OSProcess installed by default >> Image(s) with OSProcess >> >> then Metacello Preview will be functional. >> >> The reason why , i personally want that, is >> to be able to use git for monticello. and be able to store C sources >> and smalltalk sources (VMMaker) in a single git repo. > > Igor, I assume then that neither Filetree nor Gitocello meet your > needs? (Both map Monticello repositories to git.) > Well, one of the reasons why i want a preview is to figure that out: does it fits or not, and what/how it can be used. > frank > -- Best regards, Igor Stasenko.

Nov. 6, 2012

Re: [Pharo-project] NativeBoost Dev

by Igor Stasenko

On 2 November 2012 06:05, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Igor, > > in Win32 often one passes NULL as argument > (for instance if a function has an argument "handle to a window", then > a hWnd of NULL can be given). > > For instance when I have > > shellExecute: hwnd operation: lpOperation file: lpFile parameters: lpParameters directory: lpDirectory show: nShowCmd > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > > ^ self nbCall: #( > HINSTANCE ShellExecuteA( > HWND hwnd, > LPCTSTR lpOperation, > LPCTSTR lpFile, > LPCTSTR lpParameters, > LPCTSTR lpDirectory, > INT nShowCmd)) module: 'Shell32.dll' > usually it controlled by options for code generator like #optCoerceNilToNull which will allow you to pass nil as valid argument. What is missing, is that in your case you passing an instance of NBExternalObject, and NBExternalObjectType converter does not honors that option. This is easy to fix. I will add it as time allows me to do a pass on NativeBoost. > > The NBFFICallout class(NBNativeCodeGen class)>>handleFailureIn:nativeCode: > tells me that "an instance of NBWin32Window" is expected. > right, so what you can do is to synthesize an instance of NBWin32Window with handle value == 0. This will effectively behave as if you passed null argument. Sure it is not nearly elegant, so i mentioning it just for protocol :) > So currently I have to pass "NBWin32Window getFocus" as first > argument. But often this is not necessary. > Another way of doing this is use convenience methods. Like with your function, you could have two methods for it, one which takes window argument, and another which doesn't: shellExecute: lpOperation file: lpFile parameters: lpParameters directory: lpDirectory show: nShowCmd ^ self nbCall: #( HINSTANCE ShellExecuteA( 0, LPCTSTR lpOperation, LPCTSTR lpFile, LPCTSTR lpParameters, LPCTSTR lpDirectory, INT nShowCmd)) module: 'Shell32.dll' like that, you exposed API in proper way, i.e. without forcing users to pass meaningless nils every time :) and of course, in a second form (one which takes window handle as argument), you would expect a valid window handle, but not nil/null/whatever. That way it makes things less error prone. > I also havent found a constant pool with NULL or an accessor. > Whats the prefered way to deal with NULL in NB? > > > Can you also please add me as a developer > to http://www.squeaksource.com/NativeBoost > My initials are "tbn" > done. > I would like to add several API functions for > Win32 (ShellExecute, OutputDebugString, ...) > go ahead :) > Thx > Torsten -- Best regards, Igor Stasenko.

Nov. 6, 2012

Re: [Pharo-project] Pharo 2.0 and Metacello preview

by Frank Shearar

On 6 November 2012 18:07, Igor Stasenko <siguctua(a)gmail.com> wrote: > Basically, what is needed is: > VMs with OSProcess installed by default > Image(s) with OSProcess > > then Metacello Preview will be functional. > > The reason why , i personally want that, is > to be able to use git for monticello. and be able to store C sources > and smalltalk sources (VMMaker) in a single git repo. Igor, I assume then that neither Filetree nor Gitocello meet your needs? (Both map Monticello repositories to git.) frank

Nov. 6, 2012

Re: [Pharo-project] [Pharo-users] Pharo consortium agreement

by Sven Van Caekenberghe

Very good that there is progress on this front ! Even better news about Igor ;-) Indeed: thank you INRIA for sponsoring Pharo. I will read the document this evening. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill On 06 Nov 2012, at 17:24, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Dear Pharoers > > Here is the result of the work we did around the consortium for Pharo for about 2 years. We took into account all your remarks over the years > and we think that the result is good and corresponds to what the community can support. > This consortium is important for Pharo's future and it will help us to deliver a system to help you making business. > Our goal is to be able to collect fundings to pay at least one full time engineer. > > The idea is that all the consortium members will sign the same agreement. We will not handle modifications per partners. > Now since we are starting the process if you spot some glitches on the form let us know. We can discuss and fully stabilize one version. > > We suggest to read the document. > - If you agree to sign it and send it to us (in two copies if you do it by surface mail at > INRIA - S. Ducasse - Pharo, 40, avenue Halley, Parc Scientifique de la Haute Borne, > BÃ¢t.A, Park Plaza, Villeneuve d'Ascq, FR-59650, France.), so that we sign it too. > - Don't forget to complete your legal mention on first page and your contact details on article 14 before signing. :) > > We will launch soon two web sites: > - one for the Pharo user association and > - one for the Pharo consortium. > > > A side note: we will communicate about it later and separately but Inria decided to support the consortium by paying one extra year to Igor Stasenko. > This is around 60 Keuros in addition to the year of Esteban Lorenzano and previous years of Igor. > > I really want to thank Inria for the constant support and the work of S. Karpf, P. Moreau and S. Perin. > > Stef > > <2012-11-06-consortium PHARO.pdf> > > > > > ------------------------ > Dr. StÃ©phane Ducasse -- Directeur de Recherche (Senior Researcher) > INRIA - USTL - CNRS UMR 8022 > stephane.ducasse(a)inria.fr > http://stephane.ducasse.free.fr > http://rmod.lille.inria.fr/ > **NEW ***Tel 00 33 (0)3 59 35 87 52 - Fax 33 3 59 57 78 50 > > 40, avenue Halley, Parc Scientifique de la Haute Borne, > BÃ¢t.A, Park Plaza, Villeneuve d'Ascq, FR-59650, France. > > > > > > >

Nov. 6, 2012

Re: [Pharo-project] Pharo Kernel with Metacello

by Esteban Lorenzano

yep... and I need esteban := esteban ^ 2. more or less :) but we will do it, eventually :P On Nov 6, 2012, at 5:58 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Nov 6, 2012, at 2:06 PM, Pavel Krivanek wrote: > >> Hi, >> >> I created an experimental CI job that loads Metacello to the Pharo Kernel. >> >> https://ci.lille.inria.fr/pharo/view/Pharo-Kernel%202.0/job/Pharo-Kernel-2.… >> > > Excellent idea :) > I see where you are looking for and we are all looking in that direction > Now the problem is that we should change our process and generate configurations when we integrate changes. > But we want that :) > > Stef > >

Nov. 6, 2012

Re: [Pharo-project] [NativeBoost] pass an array of args to external function

by Max Leske

Cool, thanks. I'll give that a try tomorrow. On 06.11.2012, at 18:34, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 6 November 2012 11:23, Max Leske <maxleske(a)gmail.com> wrote: >> Thanks Igor. >> >> I meant a pointer to an array, sorry. Here's the function prototype: >> >> int run_command(const char *command, char *argv[]); >> >> I could then simply pass this to execve like so: >> >> status = execve(command, argv, envp); >> > so, like i said, prepare a buffer which will hold strings, i.e. > > buffer := NativeBoost allocate: (numArgs * 4). > arg1ptr := NativeBoost allocate: arg1 size+1. > > NativeBoost memcopy: arg1 to: arg1ptr size: arg1 size. > arg1ptr nbUInt8At: arg1 size put: 0. "terminating null char" > > buffer nbUInt32At: 0 put: (arg1ptr value). > > something like that. > (and then , of course free memory after you no longer need it :) > >> >> >> On 06.11.2012, at 15:12, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> well, you have to decompose it to >>> fn(arg1, arg2, arg3 ... ) >>> >>> because NB does not supports vararg functions. >>> >>> But if function takes a pointer to array, then you can just use >>> external memory buffer and fill it with >>> anything you want. >>> What exactly function you wanna use? >>> >>> On 6 November 2012 11:06, Max Leske <maxleske(a)gmail.com> wrote: >>>> Hi >>>> >>>> Working with NativeBoost I'm trying to figure out if there is a way I can pass an array of arguments to a function like so: >>>> >>>> MyExample run: 'echo' args: { 'foo' }. >>>> >>>> >>>> nbRun: str args: args >>>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > >>>> ^ self nbCall: #( int run_command (String str, Array args) ) module: 'librunner.dylib' >>>> >>>> The intention is of course to be able to pass arguments to execve() (for example). >>>> I guess I could simply parse a string on the C-side but I'd rather not. >>>> >>>> Any suggestions? >>>> >>>> Cheers, >>>> Max >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > > -- > Best regards, > Igor Stasenko. >

Nov. 6, 2012

[Pharo-project] Pharo 2.0 and Metacello preview

by Igor Stasenko

Basically, what is needed is: VMs with OSProcess installed by default Image(s) with OSProcess then Metacello Preview will be functional. The reason why , i personally want that, is to be able to use git for monticello. and be able to store C sources and smalltalk sources (VMMaker) in a single git repo. -- Best regards, Igor Stasenko.

Nov. 6, 2012

Re: [Pharo-project] [squeak-dev] Re: now that squeaksource is back...

by Frank Shearar

On 6 November 2012 17:29, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Tue, Nov 06, 2012 at 10:45:57AM +0100, Esteban Lorenzano wrote: >> Hi, >> >> I strongly recommend all of you to move your projects into one of the alternatives: >> >> http://smalltalkhub.com >> http://ss3.gemstone.com > > I would appreciate some guidance as to which of these is intended to > serve as the long term replacement for SqueakSource, and how specifically > I should go about migrating an existing project from SqueakSource to the > replacement system. Dave, Mariano's written up something which ought to help: http://marianopeck.wordpress.com/2011/11/08/migrating-projects-to-squeaksou… (I use ss3 for my new projects (but I'd rather be using GitHub).) frank > Thanks, > Dave > >

Nov. 6, 2012

Re: [Pharo-project] [NativeBoost] pass an array of args to external function

by Igor Stasenko

On 6 November 2012 11:23, Max Leske <maxleske(a)gmail.com> wrote: > Thanks Igor. > > I meant a pointer to an array, sorry. Here's the function prototype: > > int run_command(const char *command, char *argv[]); > > I could then simply pass this to execve like so: > > status = execve(command, argv, envp); > so, like i said, prepare a buffer which will hold strings, i.e. buffer := NativeBoost allocate: (numArgs * 4). arg1ptr := NativeBoost allocate: arg1 size+1. NativeBoost memcopy: arg1 to: arg1ptr size: arg1 size. arg1ptr nbUInt8At: arg1 size put: 0. "terminating null char" buffer nbUInt32At: 0 put: (arg1ptr value). something like that. (and then , of course free memory after you no longer need it :) > > > On 06.11.2012, at 15:12, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> well, you have to decompose it to >> fn(arg1, arg2, arg3 ... ) >> >> because NB does not supports vararg functions. >> >> But if function takes a pointer to array, then you can just use >> external memory buffer and fill it with >> anything you want. >> What exactly function you wanna use? >> >> On 6 November 2012 11:06, Max Leske <maxleske(a)gmail.com> wrote: >>> Hi >>> >>> Working with NativeBoost I'm trying to figure out if there is a way I can pass an array of arguments to a function like so: >>> >>> MyExample run: 'echo' args: { 'foo' }. >>> >>> >>> nbRun: str args: args >>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > >>> ^ self nbCall: #( int run_command (String str, Array args) ) module: 'librunner.dylib' >>> >>> The intention is of course to be able to pass arguments to execve() (for example). >>> I guess I could simply parse a string on the C-side but I'd rather not. >>> >>> Any suggestions? >>> >>> Cheers, >>> Max >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Nov. 6, 2012