- Pharo-dev - lists.pharo.org

[update 3.0] #30249

by Marcus Denker

30249 ----- 11047 Integrate new class builder step 2 https://pharo.fogbugz.com/f/cases/11047 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.8… http://smalltalkhub.com/mc/Pharo/Pharo30/main/SlotTests-MarcusDenker.37.diff

July 3, 2013

[update 2.0] #20610

by Marcus Denker

20610 ----- 11101 fileOutMethod:on: uncategorized in 2.0 https://pharo.fogbugz.com/f/cases/11101 â¦ and using an image with all strange processes killed.

July 3, 2013

Re: [Pharo-dev] NativeBoost with no access to sources

by Goubier Thierry

Le 03/07/2013 14:25, Igor Stasenko a Ã©crit : > On 3 July 2013 14:19, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> >> >> Le 03/07/2013 11:59, Igor Stasenko a Ã©crit : >> >>> On 3 July 2013 11:48, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>>> >>>> Is there something against that ? >>>> >>>> It seems as if NB is used to check file existence / isReadable, then, >>>> upon >>>> startup, the vm is unable to open the changes file and all NB calls >>>> becomes >>>> incorrect. >>>> >>> >>> NB callout needs argument names (which it can only get right now by >>> accessing method's source). >>> We plan to change that after introducing pluggable mechanism in opal >>> to use it to run additional >>> code on certain pragma to handle it in custom way (like remembering >>> argument names in method's properties). >> >> >> If it is like that, I have to give up any chance of correcting the file >> permissions problem on Pharo 2.0. >> >> Any chance that we could use arguments positions instead ? >> > I don't know.. look: > > realloc: flags mem: lpMem size: dwBytes > > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> > > > ^ self nbCall: > #( LPVOID HeapReAlloc (self, DWORD flags, LPVOID lpMem, SIZE_T dwBytes) ) > > here, see: flags, lpMem, dwBytes names is in function signature same > as in your method. > That's how NB knows which argument from method corresponds to argument > passed to function. > > now if you don't use argument names , how the above should look like? > > realloc: flags mem: lpMem size: dwBytes > > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> > > ^ self nbCall: > #( LPVOID HeapReAlloc (self, DWORD @1, LPVOID @2, SIZE_T @3) ) > ? > > potentially , you can change the signature parser to accept such syntax.. > but as to me, that's really ugly, counter intuitive and error prone. I'm doing that at the moment because it sounds inacceptable in 2.0 to have the following true: No use of NativeBoost if you start the VM without sources and changes. Just wait until someone deploys 2.0 in production without the sources and is unable to load environment variables... (for my own use, I'll hack either OSProcess to extend FileSystem and get correct file permissions, the ChangeFile opening to force it even if NB isn't working, or NB itself. But I don't have yet a need to deploy without the sources). Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 3, 2013

Re: [Pharo-dev] NativeBoost with no access to sources

by Igor Stasenko

On 3 July 2013 14:19, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 03/07/2013 11:59, Igor Stasenko a Ã©crit : > >> On 3 July 2013 11:48, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>> >>> Is there something against that ? >>> >>> It seems as if NB is used to check file existence / isReadable, then, >>> upon >>> startup, the vm is unable to open the changes file and all NB calls >>> becomes >>> incorrect. >>> >> >> NB callout needs argument names (which it can only get right now by >> accessing method's source). >> We plan to change that after introducing pluggable mechanism in opal >> to use it to run additional >> code on certain pragma to handle it in custom way (like remembering >> argument names in method's properties). > > > If it is like that, I have to give up any chance of correcting the file > permissions problem on Pharo 2.0. > > Any chance that we could use arguments positions instead ? > I don't know.. look: realloc: flags mem: lpMem size: dwBytes <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> ^ self nbCall: #( LPVOID HeapReAlloc (self, DWORD flags, LPVOID lpMem, SIZE_T dwBytes) ) here, see: flags, lpMem, dwBytes names is in function signature same as in your method. That's how NB knows which argument from method corresponds to argument passed to function. now if you don't use argument names , how the above should look like? realloc: flags mem: lpMem size: dwBytes <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> ^ self nbCall: #( LPVOID HeapReAlloc (self, DWORD @1, LPVOID @2, SIZE_T @3) ) ? potentially , you can change the signature parser to accept such syntax.. but as to me, that's really ugly, counter intuitive and error prone. -- Best regards, Igor Stasenko.

July 3, 2013

Re: [Pharo-dev] NativeBoost with no access to sources

by Goubier Thierry

Le 03/07/2013 11:59, Igor Stasenko a Ã©crit : > On 3 July 2013 11:48, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> Is there something against that ? >> >> It seems as if NB is used to check file existence / isReadable, then, upon >> startup, the vm is unable to open the changes file and all NB calls becomes >> incorrect. >> > > NB callout needs argument names (which it can only get right now by > accessing method's source). > We plan to change that after introducing pluggable mechanism in opal > to use it to run additional > code on certain pragma to handle it in custom way (like remembering > argument names in method's properties). If it is like that, I have to give up any chance of correcting the file permissions problem on Pharo 2.0. Any chance that we could use arguments positions instead ? Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 3, 2013

[update 3.0] #30248

by Marcus Denker

July 3, 2013

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

by kilon

yeah I know there is no such thing as types in smalltalk , since everything is an object and the language is dynamic. I was referring to how those objects map to C types. But you are correct it is simpler than I was assuming. The more I think about it the more it makes sense. Igor Stasenko wrote > On 2 July 2013 23:04, kilon < > thekilon@.co > > wrote: >> Thank you Igor for the clarifications, the reason why I prefer using the >> nativeboost methods is because : >> >> a) I was not sure if smalltalk types map correctly to C types and which >> Smalltalk types correspond to which C types > > well, there's no such thing as 'types' in smalltalk :) > >> >> b) many opengl functions ask for the address of the value and the value >> itself. And I have no clue how to obtain memory addresses of smalltalk >> types. >> > > you don't. The value can have a type, but address don't. > Address is just a location in memory, where the value(s) (could be) > stored. > > For any function which takes a pointer, you can pass an instance of > ByteArray, > or instance of NBExternalAddress to it. In first case, a pointer to > first byte of bytearray > will be passed to function, in second one , the value of address. > > So, you either allocate buffer in object memory, or external memory.. > fill it with whatever > it needs and pass to function. Does that sounds simple enough? > >> c) I was not sure whether Pharo VM or garbage collector would move my >> data >> making my pointers invalid. >> >> But if you say its ok, I trust you. When exactly is ok to use smalltalk >> types ? >> > if you pass a pointer to something in object memory into function, > make sure GC cannot move the object while function uses/accessing its > contents. > > and it is only for pointers. For arguments which is passed by value > (ints/floats), you don't have to care. > >> -- >> View this message in context: >> http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696955.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> > > > > -- > Best regards, > Igor Stasenko. -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4697076.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 3, 2013

Re: [Pharo-dev] NativeBoost with no access to sources

by Marcus Denker

On Jul 3, 2013, at 12:20 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 3 July 2013 11:48, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> Is there something against that ? >> >> It seems as if NB is used to check file existence / isReadable, then, upon >> startup, the vm is unable to open the changes file and all NB calls becomes >> incorrect. >> > > NB callout needs argument names (which it can only get right now by > accessing method's source). > We plan to change that after introducing pluggable mechanism in opal > to use it to run additional > code on certain pragma to handle it in custom way (like remembering > argument names in method's properties). > We need a high level code model. The design we have right now is from 1978. But now it is 2013. There is no need to have a code model that does not store the names of temps. Marcus

July 3, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=ma… 1 regressions found. Tests.CodeImport.ChunkImportTestCase.testImportAClassCategory

July 3, 2013

Re: [Pharo-dev] NBCodeGenRecursion:NativeBoostWin32>>#bootstrapAllocate:into:

by Igor Stasenko

On 3 July 2013 12:15, Guy Hylton <guygantuan(a)gmail.com> wrote: > My NativeBoost journey has reached the point where I would like to use some > of the NBExternalStructure extensions available in development version 2.2 > but I can't get past a NBCodeGenRecursion error which occurs when I run the > NB tests. > > I put some halts into the NB code and thought that I had cracked it because > NativeBoostWin32>>basicAllocate: calls NativeBoost>>callGateFunctionAddress > which calls NativeBoostWin32>>basicAlloate:, but then I realised that the > same thing was happening in the stable version I was using ... so I guess > that I am looking in the wrong area? > Installing the call gate function is part of bootstrap (when you first time attempt to use NB in new session) and it is essential to have it installed because without it, you cannot make calls to VM functions which allocating new objects on heap. So, the bootstrap code written carefully to not use code which allocates new objects on heap before call gate function is installed and available. And the recursion happens when you change the code which violates this rule. > Were should I look next? Cannot tell.. I need more details on what you trying to do. I am currently working on bringing things up to date (and make some fixes) and will release new config, which will be integrated into Pharo image. -- Best regards, Igor Stasenko.

July 3, 2013