July 2013 - Pharo-dev - lists.pharo.org

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

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

by Guy Hylton

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? Were should I look next?

July 3, 2013

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

by Igor Stasenko

On 2 July 2013 23:04, kilon <thekilon(a)yahoo.co.uk> 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.

July 3, 2013

Fwd: [Pharo-users] Tudor Girba joins Pharo Board

by Tudor Girba

I forgot again to push the reply all button. Doru ---------- Forwarded message ---------- From: Tudor Girba <tudor(a)tudorgirba.com> Date: Wed, Jul 3, 2013 at 9:59 AM Subject: Re: [Pharo-users] [Pharo-dev] Tudor Girba joins Pharo Board To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Hi everyone, Thanks for the wishes. Just a note: I do not see getting in the board as a prize, but as a work to do. And there is some work left :) One of the points that I will stress everyone with is the marketing of Pharo. Marketing, like any other meaningful thing, requires design. Design requires feedback. And feedback requires time. That is why we have to start with this endeavor sooner rather than later. The other thing about marketing is that it can actually be meaningful, but this happens only when we live what we sell. Pharo does offer a fantastic opportunity because when people talk about it, their eyes blink. This reveals both value and values that are packaged deep in Pharo. We just have to capitalize on that, and I want to start by making explicit what makes Pharo unique and valuable. Everyone thinks of various things, but we do not yet have a concerted message. This message, and I will aim at one single message, has to transpire in everything we do: from the way we design the code, to the concepts we adopt in the language, to the frameworks we build on top, and to the developer and user experience. This is exciting, but it requires team effort. This is where you come in. We want your energy outside of pure coding. More concrete proposals will come in the near future, but until then, feel free to chip in your ideas. Cheers, Doru On Wed, Jul 3, 2013 at 4:16 AM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > Congrats! Doru, It's well deserved. > Best, > > > On Tue, Jul 2, 2013 at 7:51 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > >> Cool! >> >> Alexandre >> >> >> On Jul 2, 2013, at 10:12 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> > Hi, >> > >> > The Pharo Board is pleased to announce that Tudor Girba has recently >> joined the Pharo Board. Among others, he will try to contribute on long >> term issues like the positioning of Pharo. >> > >> > StÃ©phane, Marcus & Sven >> > >> > http://www.pharo-project.org/about/board >> > >> > -- >> > http://pharo.org >> > http://association.pharo.org >> > http://consortium.pharo.org >> > >> > >> > >> > >> > >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > -- www.tudorgirba.com "Every thing has its own flow" -- www.tudorgirba.com "Every thing has its own flow"

July 3, 2013

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

by Igor Stasenko

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). > 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 > -- Best regards, Igor Stasenko.

July 3, 2013