On 4 July 2013 13:07, Goubier Thierry <[email protected]> wrote: > > > Le 04/07/2013 11:58, Igor Stasenko a écrit : > >> On 3 July 2013 23:04, GOUBIER Thierry <[email protected]> wrote: >>> >>> Hi Stephane, >>> >>> I worked around it... as long as I don't make FileReference>>exists as a >>> NB call, then the Changes file will open correctly and NB calls will work >>> after that (Changes opening doesn't use isReadable or isWriteable, which is >>> interesting in itself ;))... But it makes my solution fragile. >>> >>> However, if you make the Changes file not readable (still owned by you, >>> still writeable), many interesting things happen, starting with a nbGetEnv >>> failure and a total unability to quit Pharo apart from a killall pharo. >>> >>> I tried to: >>> - Get NB to accept positional arguments instead of named ones (by >>> catching names like _1, _2). Easy, since apparently the NB generated code >>> just takes an offset on the pointer stack finally (i.e. names are only used >>> to get the index in the arguments array). Seemed to work. >> >> >> can you share this code? i think it doesn't hurts being able to refer >> to method argument by number , not by name, if author wants to. > > > I wondered if it could be both (name and number), but went for the shortest > path, that is the simplest solution: > > NBFFICallout>>loaderFromMethodArgsNamed: argName > > methodArgs > ifNotNil: [ > | index | > (argName first = $_ and: [ argName allButFirst > isAllDigits ]) > ifTrue: [ ^ NBSTMethodArgument new > stackIndex: methodArgs size - argName asUnsignedInteger ]. > index := methodArgs indexOf: argName ifAbsent: [ nil > ]. > index > ifNotNil: [ > "ok, this is a method argument" > ^ NBSTMethodArgument new stackIndex: > methodArgs size - index ] ]. > ^ nil > This looks fine , and i will add it into NB.
> Then I tried to change all calls to use numbers, but it ended in a Segfault > (not in NB itself, but somewhere else as if I had a corrupted heap). The end > result with all changes is there: > > http://ss3.gemstone.com/ss/PharoInbox/SLICE-Issue-11102-FileSystemError-Path--root-ThierryGoubier.4.mcz > > If you see where I missed something, I'd be happy to know. > you probably made a mistake somewhere. ;) because counting the argument index, instead of putting its name is error prone. > >>> - Change all NB calls with numbers above to be able to have NB working >>> before / without the Changes file. >>> Ended with a segfault on startup (globalSymbolLoading for GetEnv >>> again), and I gave up. >>> >>> Igor, would there be a way to write the call with the effective arguments >>> instead of #symbols, so that by looking at the bytecode you would get the >>> position in the arguments stack? Or would it be possible to store by hand >>> the source of the methods (triggered by the <pragma>) inside a source cache >>> inside NB for the time being? Or is there an event for NB correct start >>> (with Changes and all ready) so that we can write NB code with a fallback if >>> NB isn't able to work? >>> >> i wanna change it, so that when you compile method with NB primitive, >> it remembers the arg names. > > > Yes, I suspect it would be the best solution. Trap on <primitive: ? If you > track the MethodAdded / MethodRemoved events, you can note all uses of > <primitive:> and cache the info there ? > not cache, just put it into method's attributes, so i can access them later. And not when method added/removed, but at compilation time. > -- Best regards, Igor Stasenko.
