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

Re: [Pharo-dev] NAtiveBoost error

by kilon alios

Its definetly an interesting concept. I am curious to give it a try because it would take me outside my comfort zone and there is nothing more that I love than getting outside my comfort zone. But I blame Pharo and the Pharo people who dont let me to try another language, damn them !!!! DAMN THEM I SAY!!!! Side effects certainly can be a source of trouble but alas they are not the holy grail of trouble. Coding is a complex subject so introducing restrictions of purity will produce some side effects. OH YES PUN WAS INTENDED !!!! Its easy to dismiss such an approach however without trying it in practice with real projects. But then I do also recognise that mixing types can be a problem too at some point that does not convince me into going to static type language. I think for Pharo state is much less of a problem because Pharo has very powerful inspector , debuger and IDE to track down state. So its easy for a pharo developer to be aware of state compared to some developer using another language and not using an IDE at all. If state becomes too complex then its a sign to refactor code and make it simpler. I do think however with powerful IDEs you can get around this problem easily. So I cant say I am a big believer of Haskell. Also I real hate the terminology "side effect" ... sounds too..... elitist to me. On Fri, Nov 7, 2014 at 5:51 PM, Kjell Godo <squeaklist(a)gmail.com> wrote: > This is off topic. > > I tried to post it as a top level thread but I have become unknown. > > I don't know if you want this crap in here but I have decided not to wait > for the > > postmaster to get back to me on the subject of becoming known. Feel free. > > > > > > ( Original-SUBJECT: "( picoVerse-:( what about state , is state really > evil? ) )" ) > > > > > > > I am a Smalltalker. > > But in the past few months i have been running with the Haskellers. > > The Haskellers hate state. > > This seemed strange at first because as a Smalltalker i love(d) state. > State iswas my friend. > > 90% of my life as a Smalltalker is state wrangling. I am a state herder. > > The debugger is my staff I use to whack the state. And TestCase is my > sheep dog. > > But to the Haskellers > > state is > > the evil trinity > > of > > satan the anti christ and the false prophet > > all rolled into one. > > State is the true dev incarnation of the total catastrophe of development > Armageddon. > > Blood up to the bridles for hundreds of miles. Dogs and cats living > together. Mass hysteria. > > They say. > > I'm not sure i quite get it yet but they keep preaching on this one point > most of all. > > State is evil. > > You must keep all state in a Monad. As many methods/functions m as > possible > > must be 100% dependent on the input parameters ONLY. > > No hidden instance variables affecting the return value of m are allowed. > > The only effect m can have is to return a value. > > If all this is true then m is pure. > > And pure is good. Pure is very good. And the wind says > > very. > > So i wonder if any of you fellow > > Smalltalkers > > have thought about this at all. > > Thanks > > Kjell E GodÃ¸ > > > > > > > > > > (((((((((( Maybe Smalltalk should be called Statewalk > > as in yak it up fuzz ball. )))))))))) > > > On Tuesday, November 4, 2014, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > >> Stef, >> As I said to Igor, the main problem about NativeBoost was between >> the chair and the keyboard... :) >> It is my first use of NativeBoost, I simply overlooked the very good >> existing chapter of EnterprisePharo on NativeBoost >> (NativeBoost recipes, the X11 journey) and misused the >> NativeBoost marshalling of data types. >> NAtiveBoost is great. >> >> If I achieve my experiments with zeromq and ends up with >> something clean (not the case actually, and not my first goal), >> I will be glad to add a chapter about that. >> >> My current problem is about a different socket behaviour between >> windows and linux. >> I think this is not a problem with ZeroMQ, the C program works as >> expected, >> I have to look for an explanation. >> No stress about that >> >> >> Alain >> >> >> Le 04/11/2014 10:39, stepharo a Ã©crit : >> >>> Alain >>> >>> which nativeboost chapter :)? >>> Could you propose a paragraph so that we cover the problem you faced? >>> >>> Stef >>> >>> On 4/11/14 00:44, Alain Rastoul wrote: >>> >>>> Hi Igor, >>>> >>>> Thank you for your answer, it worked perfectly >>>> Looks like I overlooked the nativeboost chapter >>>> .. 10 timesRepeatAfterMe: [self rtfm ] . >>>> And my suggestion about testing nil was stupid, much better to fail >>>> soon. >>>> ... I am an ass on this one... >>>> >>>> However, I am struggling on another point you already answered in the >>>> past >>>> in the mailing list to a guy who wanted to use socket.io : >>>> (http://forum.world.st/socket-io-td3891592.html#a3893031) >>>> "Sockets in Pharo are not blocking the whole VM. >>>> What they block is the process which working with concrete socket. But >>>> other processes can still run, while >>>> one waiting data / even from single socket. " >>>> on windows, zmq socket receive is blocking, on linux, not blocking >>>> (hence not working). >>>> As zmq is doing is IO on another thread, I guess there is some side >>>> effect of >>>> socket receive timeout settings somewhere (in the plugin ?) - just a >>>> guess... >>>> Getting socket options shows no difference, but I don't know how it is >>>> done on the vm >>>> side with regards to threads and if the socket is the same (zmq socket >>>> is not the tcp socket)... >>>> And on linux, the equivalent C program of to the smalltalk version >>>> blocks as expected. >>>> >>>> I a mperplexified ... >>>> may be I should look at vm and plugin code (VMMaker package IIRC) ? >>>> Do you have another advice ? >>>> >>>> Thanks you >>>> >>>> Alain >>>> Le 03/11/2014 02:12, Igor Stasenko a Ã©crit : >>>> >>>>> NBExternalArray instances cannot be passed directly to functions >>>>> expecting pointers. >>>>> >>>>> use 'myarray address' for arguments. >>>>> >>>>> On 3 November 2014 00:20, Alain Rastoul >>>>> <alf.mmm.cat(a)gmail.com >>>>> <mailto:alf.mmm.cat@gmail.com>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I have a problem with a nativeboost call, but I don't see what I >>>>> do >>>>> wrong. >>>>> >>>>> library function prototype is: >>>>> int zmq_getsockopt (void *socket, int option_name, void >>>>> *option_value, size_t *option_len); >>>>> >>>>> my calling method in pharo is: >>>>> zmq_getsockopt: socket option_name: option_name option_value: >>>>> option_value option_len: option_len >>>>> <primitive: #primitiveNativeCall module: >>>>> #NativeBoostPlugin >>>>> error: errorCode> >>>>> ^self nbCall: #(int zmq_getsockopt (void *socket, int >>>>> option_name, void * option_value, size_t* option_len) ) >>>>> >>>>> when I call it with >>>>> ... >>>>> optionValue := (NBExternalArray ofType: 'int') externalNew: 1. >>>>> optionLen := (NBExternalArray ofType: 'size_t' ) externalNew: 1. >>>>> [ optionValue at: 1 put: 0 . >>>>> optionLen at: 1 put: (NBExternalType sizeOf: 'int') . >>>>> rc := self zmq_getsockopt: socket option_name: option_name >>>>> option_value: optionValue >>>>> option_len: optionLen . >>>>> value := optionValue at: 1 . >>>>> ] ensure: [ optionValue free. >>>>> optionLen free ]. >>>>> ... >>>>> I allways get an exception: "error during FFI call : nil" >>>>> >>>>> >>>>> After stepping in NBFFICallout generation, I found something >>>>> strange, the code >>>>> generation seems not to be called because lastError stays at nil ? >>>>> >>>>> handleFailureIn: aContext nativeCode: aBlock >>>>> lastError := self getErrorFrom: aContext lastError: >>>>> NativeBoost lastError. >>>>> >>>>> >>getErrorFrom: aContext lastError: errorCode >>>>> ... checks pragmas etc >>>>> >>getErrorFrom: aContext lastError: errorCode >>>>> ... lastError := aContext tempAt: method >>>>> numTemps. >>>>> => lastError = nil ??? shouldn't be >>>>> ErrNoNativeCodeInMethod ? >>>>> "install native code and retry the send" >>>>> lastError = ErrNoNativeCodeInMethod >>>>> ifTrue: [ ^ self generateCode: aBlock andRetry: >>>>> aContext ]. >>>>> never gets called ... >>>>> >>>>> "ok, we're out of options, signal an error here" >>>>> ^ self signalError: lastError >>>>> >>>>> Could it be because I use this image on windows and unix ? >>>>> Or because I had an exception at prototype parsing the first time >>>>> because I forgot a ; at the end of the prototype ? >>>>> >>>>> Is my prototype correct or is it the origin of the error ? >>>>> Is there a way to reset the lastError (aContext tempAt: method >>>>> numTemps) ? >>>>> I will try to reset it in debugger but may be there is a cleaner >>>>> way ? >>>>> would it be ok to change the test in handleFailure to >>>>> (lastError = ErrNoNativeCodeInMethod) or:[ lastError isNil ] ? >>>>> (I can open a bug in this case ) >>>>> >>>>> Any idea or comment is welcome >>>>> Thanks in advance >>>>> >>>>> Alain >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >>

Nov. 7, 2014

Re: [Pharo-dev] Browse anObject?

by stepharo

:) we can rename browse into browseClass. On 6/11/14 00:07, Sean P. DeNigris wrote: > Ben Coman wrote >> I thoughtâ¦ the least surprising would be... >> >> Object>>#browse >> self browseClass > This was exactly what I was objecting to. How is #browse sent to anObject > not surprising when you mean #browseClass (which already exists)? Saying > that "what else could browse mean in this context?" looks at the issue from > someone who is already an expert. The point is that it may mean nothing to a > newbie, and rightly so because IMHO it /is/ meaningless. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Browse-anObject-tp4788401p4788650.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Nov. 7, 2014

Re: [Pharo-dev] NAtiveBoost error

by stepharo

On 4/11/14 20:30, Alain Rastoul wrote: > Stef, > As I said to Igor, the main problem about NativeBoost was between > the chair and the keyboard... :) > It is my first use of NativeBoost, I simply overlooked the very good > existing chapter of EnterprisePharo on NativeBoost > (NativeBoost recipes, the X11 journey) and misused the > NativeBoost marshalling of data types. > NAtiveBoost is great. > > If I achieve my experiments with zeromq and ends up with > something clean (not the case actually, and not my first goal), > I will be glad to add a chapter about that. ok je le note ;) > > My current problem is about a different socket behaviour between > windows and linux. > I think this is not a problem with ZeroMQ, the C program works as > expected, > I have to look for an explanation. > No stress about that > > > Alain > > > Le 04/11/2014 10:39, stepharo a Ã©crit : >> Alain >> >> which nativeboost chapter :)? >> Could you propose a paragraph so that we cover the problem you faced? >> >> Stef >> >> On 4/11/14 00:44, Alain Rastoul wrote: >>> Hi Igor, >>> >>> Thank you for your answer, it worked perfectly >>> Looks like I overlooked the nativeboost chapter >>> .. 10 timesRepeatAfterMe: [self rtfm ] . >>> And my suggestion about testing nil was stupid, much better to fail >>> soon. >>> ... I am an ass on this one... >>> >>> However, I am struggling on another point you already answered in the >>> past >>> in the mailing list to a guy who wanted to use socket.io : >>> (http://forum.world.st/socket-io-td3891592.html#a3893031) >>> "Sockets in Pharo are not blocking the whole VM. >>> What they block is the process which working with concrete socket. But >>> other processes can still run, while >>> one waiting data / even from single socket. " >>> on windows, zmq socket receive is blocking, on linux, not blocking >>> (hence not working). >>> As zmq is doing is IO on another thread, I guess there is some side >>> effect of >>> socket receive timeout settings somewhere (in the plugin ?) - just a >>> guess... >>> Getting socket options shows no difference, but I don't know how it is >>> done on the vm >>> side with regards to threads and if the socket is the same (zmq socket >>> is not the tcp socket)... >>> And on linux, the equivalent C program of to the smalltalk version >>> blocks as expected. >>> >>> I a mperplexified ... >>> may be I should look at vm and plugin code (VMMaker package IIRC) ? >>> Do you have another advice ? >>> >>> Thanks you >>> >>> Alain >>> Le 03/11/2014 02:12, Igor Stasenko a Ã©crit : >>>> NBExternalArray instances cannot be passed directly to functions >>>> expecting pointers. >>>> >>>> use 'myarray address' for arguments. >>>> >>>> On 3 November 2014 00:20, Alain Rastoul >>>> <alf.mmm.cat(a)gmail.com >>>> <mailto:alf.mmm.cat@gmail.com>> wrote: >>>> >>>> Hi, >>>> >>>> I have a problem with a nativeboost call, but I don't see what >>>> I do >>>> wrong. >>>> >>>> library function prototype is: >>>> int zmq_getsockopt (void *socket, int option_name, void >>>> *option_value, size_t *option_len); >>>> >>>> my calling method in pharo is: >>>> zmq_getsockopt: socket option_name: option_name option_value: >>>> option_value option_len: option_len >>>> <primitive: #primitiveNativeCall module: >>>> #NativeBoostPlugin >>>> error: errorCode> >>>> ^self nbCall: #(int zmq_getsockopt (void *socket, int >>>> option_name, void * option_value, size_t* option_len) ) >>>> >>>> when I call it with >>>> ... >>>> optionValue := (NBExternalArray ofType: 'int') externalNew: 1. >>>> optionLen := (NBExternalArray ofType: 'size_t' ) externalNew: 1. >>>> [ optionValue at: 1 put: 0 . >>>> optionLen at: 1 put: (NBExternalType sizeOf: 'int') . >>>> rc := self zmq_getsockopt: socket option_name: >>>> option_name >>>> option_value: optionValue >>>> option_len: optionLen . >>>> value := optionValue at: 1 . >>>> ] ensure: [ optionValue free. >>>> optionLen free ]. >>>> ... >>>> I allways get an exception: "error during FFI call : nil" >>>> >>>> >>>> After stepping in NBFFICallout generation, I found something >>>> strange, the code >>>> generation seems not to be called because lastError stays at nil ? >>>> >>>> handleFailureIn: aContext nativeCode: aBlock >>>> lastError := self getErrorFrom: aContext lastError: >>>> NativeBoost lastError. >>>> >>>> >>getErrorFrom: aContext lastError: errorCode >>>> ... checks pragmas etc >>>> >>getErrorFrom: aContext lastError: errorCode >>>> ... lastError := aContext tempAt: method >>>> numTemps. >>>> => lastError = nil ??? shouldn't be >>>> ErrNoNativeCodeInMethod ? >>>> "install native code and retry the send" >>>> lastError = ErrNoNativeCodeInMethod >>>> ifTrue: [ ^ self generateCode: aBlock andRetry: >>>> aContext ]. >>>> never gets called ... >>>> >>>> "ok, we're out of options, signal an error here" >>>> ^ self signalError: lastError >>>> >>>> Could it be because I use this image on windows and unix ? >>>> Or because I had an exception at prototype parsing the first time >>>> because I forgot a ; at the end of the prototype ? >>>> >>>> Is my prototype correct or is it the origin of the error ? >>>> Is there a way to reset the lastError (aContext tempAt: method >>>> numTemps) ? >>>> I will try to reset it in debugger but may be there is a cleaner >>>> way ? >>>> would it be ok to change the test in handleFailure to >>>> (lastError = ErrNoNativeCodeInMethod) or:[ lastError isNil ] ? >>>> (I can open a bug in this case ) >>>> >>>> Any idea or comment is welcome >>>> Thanks in advance >>>> >>>> Alain >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>> >>> >>> >>> >> >> >> > > > >

Nov. 7, 2014

Re: [Pharo-dev] Should Nautilus use Rubric?

by Tudor Girba

Indeed. Really great! Doru -- www.tudorgirba.com "Every thing has its own flow" > On 07 Nov 2014, at 18:23, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > > This is the great news! Thanks! > > Juraj > >> On Nov 7, 2014, at 10:52 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> Actually, Iâm (finally) about to integrate it (an alpha version). >> it will be in the image next week :P >> >> Esteban >> >>> On 07 Nov 2014, at 14:32, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> I think we should submit TxModel to the vaporware awards 2014 :) >>> >>> Norbert >>> >>>> Am 07.11.2014 um 14:24 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: >>>> >>>> I would say yes. >>>> we would like to have rubric everywhere we need a real editor :) >>>> (while waiting for the new TxModel, this is the âless pain pathâ, IMO) >>>> >>>> Esteban >>>> >>>>> On 07 Nov 2014, at 14:07, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: >>>>> >>>>> Hi! >>>>> >>>>> Is it worth to integrate Rubric into Nautilus? Or is there any reason not to do it? >>>>> >>>>> Thank you a lot! >>>>> Juraj > >

Nov. 7, 2014

Re: [Pharo-dev] edit values in GTInspector

by Tudor Girba

Hi Sven, Neither of these requests are being ignored (see the other two replies), but good things take time. We would be happy to get more contributors :). Doru -- www.tudorgirba.com "Every thing has its own flow" > On 07 Nov 2014, at 19:31, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > It simply has to be possible to edit values and to see live updates, there is no way around it - else the GT inspector looks at dead objects, bye bye live programming. > > I think it is not cool that this is being ignored. > >> On 07 Nov 2014, at 19:24, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> >> This is strange, I do not remember to have use this when I was using the old inspector. I usually trust what the inspector tells me only having open one. >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >>> On Nov 7, 2014, at 12:40 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> Yes, editing state and inspectors need to be updated so you see live how value are changing even when they >>> are changed from somewhere else. >> > >

Nov. 7, 2014

Re: [Pharo-dev] NAtiveBoost error

by Alain Rastoul

yeah, big electron computation over the wire will tell open your chakras to monads or die :) Le 07/11/2014 19:03, Marcus Denker a Ã©crit : > > Hmmâ¦ to me this mail looks like it is written by a Bot ? > > e.g. in a mailing list everyone can start a top level thread. unknown users > can not post at all. > > And I am the âpostmasterâ of this list and I have not gotten any > requests at all... > > >> On 07 Nov 2014, at 16:51, Kjell Godo >> <squeaklist(a)gmail.com >> <mailto:squeaklist@gmail.com>> wrote: >> >> This is off topic. >> >> I tried to post it as a top level thread but I have become unknown. >> >> I don't know if you want this crap in here but I have decided not to >> wait for the >> >> postmaster to get back to me on the subject of becoming known. Feel free. >> >> >> >> >> >> ( Original-SUBJECT: "( picoVerse-:( what about state , is state >> really evil? ) )" ) >> >> >> >> >> >> >> I am a Smalltalker. >> >> But in the past few months i have been running with the Haskellers. >> >> The Haskellers hate state. >> >> This seemed strange at first because as a Smalltalker i love(d) >> state. State iswas my friend. >> >> 90% of my life as a Smalltalker is state wrangling. I am a state herder. >> >> The debugger is my staff I use to whack the state. And TestCase is my >> sheep dog. >> >> But to the Haskellers >> >> state is >> >> the evil trinity >> >> of >> >> satan the anti christ and the false prophet >> >> all rolled into one. >> >> State is the true dev incarnation of the total catastrophe of >> development Armageddon. >> >> Blood up to the bridles for hundreds of miles. Dogs and cats living >> together. Mass hysteria. >> >> They say. >> >> I'm not sure i quite get it yet but they keep preaching on this one >> point most of all. >> >> State is evil. >> >> You must keep all state in a Monad. As many methods/functions m as >> possible >> >> must be 100% dependent on the input parameters ONLY. >> >> No hidden instance variables affecting the return value of m are allowed. >> >> The only effect m can have is to return a value. >> >> If all this is true then m is pure. >> >> And pure is good. Pure is very good. And the wind says >> >> very. >> >> So i wonder if any of you fellow >> >> Smalltalkers >> >> have thought about this at all. >> >> Thanks >> >> Kjell E GodÃ¸ >> >> >> >> >> >> >> >> >> >> (((((((((( Maybe Smalltalk should be called Statewalk >> >> as in yak it up fuzz ball. )))))))))) >> >> >> On Tuesday, November 4, 2014, Alain Rastoul >> <alf.mmm.cat(a)gmail.com >> <mailto:alf.mmm.cat@gmail.com>> wrote: >> >> Stef, >> As I said to Igor, the main problem about NativeBoost was between >> the chair and the keyboard... :) >> It is my first use of NativeBoost, I simply overlooked the very good >> existing chapter of EnterprisePharo on NativeBoost >> (NativeBoost recipes, the X11 journey) and misused the >> NativeBoost marshalling of data types. >> NAtiveBoost is great. >> >> If I achieve my experiments with zeromq and ends up with >> something clean (not the case actually, and not my first goal), >> I will be glad to add a chapter about that. >> >> My current problem is about a different socket behaviour between >> windows and linux. >> I think this is not a problem with ZeroMQ, the C program works as >> expected, >> I have to look for an explanation. >> No stress about that >> >> >> Alain >> >> >> Le 04/11/2014 10:39, stepharo a Ã©crit : >> >> Alain >> >> which nativeboost chapter :)? >> Could you propose a paragraph so that we cover the problem you >> faced? >> >> Stef >> >> On 4/11/14 00:44, Alain Rastoul wrote: >> >> Hi Igor, >> >> Thank you for your answer, it worked perfectly >> Looks like I overlooked the nativeboost chapter >> .. 10 timesRepeatAfterMe: [self rtfm ] . >> And my suggestion about testing nil was stupid, much >> better to fail soon. >> ... I am an ass on this one... >> >> However, I am struggling on another point you already >> answered in the >> past >> in the mailing list to a guy who wanted to use socket.io >> <http://socket.io/> : >> (http://forum.world.st/socket-__io-td3891592.html#a3893031 >> <http://forum.world.st/socket-io-td3891592.html#a3893031>) >> "Sockets in Pharo are not blocking the whole VM. >> What they block is the process which working with concrete >> socket. But >> other processes can still run, while >> one waiting data / even from single socket. " >> on windows, zmq socket receive is blocking, on linux, not >> blocking >> (hence not working). >> As zmq is doing is IO on another thread, I guess there is >> some side >> effect of >> socket receive timeout settings somewhere (in the plugin >> ?) - just a >> guess... >> Getting socket options shows no difference, but I don't >> know how it is >> done on the vm >> side with regards to threads and if the socket is the same >> (zmq socket >> is not the tcp socket)... >> And on linux, the equivalent C program of to the smalltalk >> version >> blocks as expected. >> >> I a mperplexified ... >> may be I should look at vm and plugin code (VMMaker >> package IIRC) ? >> Do you have another advice ? >> >> Thanks you >> >> Alain >> Le 03/11/2014 02:12, Igor Stasenko a Ã©crit : >> >> NBExternalArray instances cannot be passed directly to >> functions >> expecting pointers. >> >> use 'myarray address' for arguments. >> >> On 3 November 2014 00:20, Alain Rastoul >> <alf.mmm.cat(a)gmail.com >> <mailto:alf.mmm.cat@gmail.com>> >> wrote: >> >> Hi, >> >> I have a problem with a nativeboost call, but I >> don't see what I do >> wrong. >> >> library function prototype is: >> int zmq_getsockopt (void *socket, int >> option_name, void >> *option_value, size_t *option_len); >> >> my calling method in pharo is: >> zmq_getsockopt: socket option_name: option_name >> option_value: >> option_value option_len: option_len >> <primitive: #primitiveNativeCall module: >> #NativeBoostPlugin >> error: errorCode> >> ^self nbCall: #(int zmq_getsockopt (void >> *socket, int >> option_name, void * option_value, size_t* >> option_len) ) >> >> when I call it with >> ... >> optionValue := (NBExternalArray ofType: 'int') >> externalNew: 1. >> optionLen := (NBExternalArray ofType: 'size_t' ) >> externalNew: 1. >> [ optionValue at: 1 put: 0 . >> optionLen at: 1 put: (NBExternalType >> sizeOf: 'int') . >> rc := self zmq_getsockopt: socket >> option_name: option_name >> option_value: optionValue >> option_len: optionLen . >> value := optionValue at: 1 . >> ] ensure: [ optionValue free. >> optionLen free ]. >> ... >> I allways get an exception: "error during FFI call >> : nil" >> >> >> After stepping in NBFFICallout generation, I found >> something >> strange, the code >> generation seems not to be called because >> lastError stays at nil ? >> >> handleFailureIn: aContext nativeCode: aBlock >> lastError := self getErrorFrom: aContext >> lastError: >> NativeBoost lastError. >> >> >>getErrorFrom: aContext lastError: errorCode >> ... checks pragmas etc >> >>getErrorFrom: aContext lastError: errorCode >> ... lastError := aContext >> tempAt: method >> numTemps. >> => lastError = nil ??? shouldn't be >> ErrNoNativeCodeInMethod ? >> "install native code and retry the send" >> lastError = ErrNoNativeCodeInMethod >> ifTrue: [ ^ self generateCode: >> aBlock andRetry: >> aContext ]. >> never gets called ... >> >> "ok, we're out of options, signal an >> error here" >> ^ self signalError: lastError >> >> Could it be because I use this image on windows >> and unix ? >> Or because I had an exception at prototype parsing >> the first time >> because I forgot a ; at the end of the prototype ? >> >> Is my prototype correct or is it the origin of the >> error ? >> Is there a way to reset the lastError (aContext >> tempAt: method >> numTemps) ? >> I will try to reset it in debugger but may be >> there is a cleaner >> way ? >> would it be ok to change the test in handleFailure to >> (lastError = ErrNoNativeCodeInMethod) or:[ >> lastError isNil ] ? >> (I can open a bug in this case ) >> >> Any idea or comment is welcome >> Thanks in advance >> >> Alain >> >> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> >> >> >> >> >> >> >> >> >

Nov. 7, 2014

Gofer loadDevelopment Bug?

by Sean P. DeNigris

The following, although seemingly equivalent, produce different results... #1: Gofer it smalltalkhubUser: 'SeanDeNigris' project: 'SeansPlayground'; configurationOf: 'LivingCode'; load. #ConfigurationOfLivingCode asClass project development load. VS. #2: Gofer it smalltalkhubUser: 'SeanDeNigris' project: 'SeansPlayground'; configurationOf: 'LivingCode'; loadDevelopment #1 correctly loads package dependencies which #2 fails to load. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Gofer-loadDevelopment-Bug-tp4788987.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 7, 2014

Re: [Pharo-dev] edit values in GTInspector

by Aliaksei Syrel

Hi all, We worked on it and came out with a prototype version. It will be possible to enter edition mode double clicking on the value. The problem we are facing is performance issues with Rubric when changing text mode from plain text to smalltalk code for syntax highlighting, to assign to the variable a value of the expression's result. Thank you for your feedback. Cheers, Alex On Nov 7, 2014 7:31 PM, "Sven Van Caekenberghe" <sven(a)stfx.eu> wrote: > It simply has to be possible to edit values and to see live updates, there > is no way around it - else the GT inspector looks at dead objects, bye bye > live programming. > > I think it is not cool that this is being ignored. > > > On 07 Nov 2014, at 19:24, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > > > This is strange, I do not remember to have use this when I was using the > old inspector. I usually trust what the inspector tells me only having open > one. > > > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > >> On Nov 7, 2014, at 12:40 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> > >> Yes, editing state and inspectors need to be updated so you see live > how value are changing even when they > >> are changed from somewhere else. > > > > >

Nov. 7, 2014

Re: [Pharo-dev] fixing 'format on display' and 'format on accept'

by stepharo

I like the idea because I would like to have all the code reformatted. Stef On 4/11/14 18:09, Paul DeBruicker wrote: > Hi - > > I'm going to get 'format on display' and 'format on accept' working in Nautilus. In Pharo 3 in the settings browser under 'code browsing' there is a 'pretty print' check box. As far as I can tell it doesn't affect code displaying at all in Nautilus. > > > Is it OK to repurpose that checkbox as a control for 'format on display' and to also add a check box right there for 'format on accept' ? If not what would be better? > > > Thanks > > Paul >

Nov. 7, 2014

Re: [Pharo-dev] edit values in GTInspector

by Andrei Chis

The feature for editing values in place is already implemented, just for some reasons related to changing the styling in a text editor it was slower than we wanted it to be so it wasn't enabled yet. We'll add it soon. I'm away from my computer this week :) Cheers, Andrei On Fri, Nov 7, 2014 at 3:31 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > It simply has to be possible to edit values and to see live updates, there > is no way around it - else the GT inspector looks at dead objects, bye bye > live programming. > > I think it is not cool that this is being ignored. > > > On 07 Nov 2014, at 19:24, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > > > This is strange, I do not remember to have use this when I was using the > old inspector. I usually trust what the inspector tells me only having open > one. > > > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > >> On Nov 7, 2014, at 12:40 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> > >> Yes, editing state and inspectors need to be updated so you see live > how value are changing even when they > >> are changed from somewhere else. > > > > >

Nov. 7, 2014