- Pharo-dev - lists.pharo.org

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

by stepharo

Esteban This is the best way to make sure that TxText will never get any traction. People should have a look at TxText and help. Igor cannot finish it alone. Stef On 7/11/14 14:24, Esteban Lorenzano wrote: > 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. 8, 2014

Re: [Pharo-dev] NAtiveBoost error

by Sven Van Caekenberghe

> On 08 Nov 2014, at 00:23, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > > BTW, I have the websocket B plan for that (first tests make me > think it could be a better plan for my needs). > It will be a different animal, but interesting too. About Zinc Web Sockets: https://github.com/svenvc/docs/blob/master/zinc/zinc-websockets-paper.md But there is also 'STAMP', a STOMP implementation, which is a generic message queue client: https://github.com/svenvc/docs/blob/master/neo/stamp.md Both are pure Pharo. Sven

Nov. 8, 2014

Re: [Pharo-dev] edit values in GTInspector

by Tudor Girba

What Alex was saying is that he only trusts an inspector that he just opened. This is clearly not ideal. Is there a way to get reliably notified when an object changes its state? Cheers, Doru On Sat, Nov 8, 2014 at 7:37 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > 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. > > > > But thatâs the point: if the value changes, the inspector shows the old > one. So you can *not* trust it. > (and all the cool demos do not work anymore: adding an ivar to a class and > the inspector on the object shows > it, inspecting the world and showing how the mouse course position > changesâ¦) > > Marcus > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 8, 2014

Re: [Pharo-dev] inria survey

by Thierry Goubier

2014-11-08 7:32 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > > > I've completed it, but some ambiguities I encountered... > > > > What is "Vulgarization of science" > > French people think it is the english translation of the french word > "vulgarisation scientifique" > http://fr.wikipedia.org/wiki/Vulgarisation > > It seems to be in the english dictionary as "to make popular": > http://dictionary.reverso.net/english-definition/vulgarisation > > (coming from latin I guess lots of languages have it with kind-of-the same > meaning.) > For my german ear it sound horrible, as "vulgÃ¤r" has picked up *very* > negative > connotations. > > You really do not want to be that... or make your research that: > http://www.dict.cc/deutsch-englisch/vulgÃ¤r.html > Knowing that "vulgaire" in french has more or less the same meaning than "vulgÃ¤r" in German :) Thierry > > > Marcus > > > > >

Nov. 8, 2014

Re: [Pharo-dev] Visit/accept method naming philosophy

by Thierry Goubier

Hi Ben, 2014-11-08 7:28 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > This is a general query and something I've wondered several times before > in different situations, but I use OSWindow as an example since that is > what I happen to be looking at this time. > > For curiosity I was having a poke around OSWindow and seeing > OSWindowMorphicEventHandler>>handleEvent: > morphicEvent := anEvent accept: self. > > I wanted to view the code that could invoke, so I used <cmd-M> on #accept: > to get the implementors, which lists 116 items, many of which are > unrelated. Now its not toooo hard to "guess" which implementations are > related, but it would be nicer to guess less. Would it be a reasonable > philosophy to distinguish each package's #accept: method by appending the > expect object type, like this... ? > > > OSWindowMorphicEventHandler>>handleEvent: > morphicEvent := anEvent acceptOSEventHandler: self. > > IRVisitor>>visitNode: elem > ^ elem acceptIRVisitor: self > > ParseNodeVisitor>>visitBlockNode: aBlockNode > aBlockNode statements do: > [:statement | statement acceptParseNode: self] > > > Or does such a convention constrain too much how you can extend a visitor > pattern? > It has a nice "a type is documentation for the programmer" effect, so I'd say it could work. It would be interesting to see what it looks like on an external package of a certain size and with users. At the same time, your issue is also with the fact that filtering the relevant #accept: implementors could be easier, and this is a GUI issue for which we already have propositions (or we can think of some). Thierry > > cheers -ben > > > > >

Nov. 8, 2014

Re: [Pharo-dev] edit values in GTInspector

by Marcus Denker

> 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. > But thatâs the point: if the value changes, the inspector shows the old one. So you can *not* trust it. (and all the cool demos do not work anymore: adding an ivar to a class and the inspector on the object shows it, inspecting the world and showing how the mouse course position changesâ¦) Marcus

Nov. 8, 2014

Re: [Pharo-dev] inria survey

by Marcus Denker

> > I've completed it, but some ambiguities I encountered... > > What is "Vulgarization of scienceâ French people think it is the english translation of the french word "vulgarisation scientifique" http://fr.wikipedia.org/wiki/Vulgarisation It seems to be in the english dictionary as âto make popularâ: http://dictionary.reverso.net/english-definition/vulgarisation (coming from latin I guess lots of languages have it with kind-of-the same meaning.) For my german ear it sound horrible, as âvulgÃ¤râ has picked up *very* negative connotations. You really do not want to be thatâ¦ or make your research that: http://www.dict.cc/deutsch-englisch/vulgÃ¤r.html Marcus

Nov. 8, 2014

Visit/accept method naming philosophy

by Ben Coman

This is a general query and something I've wondered several times before in different situations, but I use OSWindow as an example since that is what I happen to be looking at this time. For curiosity I was having a poke around OSWindow and seeing OSWindowMorphicEventHandler>>handleEvent: morphicEvent := anEvent accept: self. I wanted to view the code that could invoke, so I used <cmd-M> on #accept: to get the implementors, which lists 116 items, many of which are unrelated. Now its not toooo hard to "guess" which implementations are related, but it would be nicer to guess less. Would it be a reasonable philosophy to distinguish each package's #accept: method by appending the expect object type, like this... ? OSWindowMorphicEventHandler>>handleEvent: morphicEvent := anEvent acceptOSEventHandler: self. IRVisitor>>visitNode: elem ^ elem acceptIRVisitor: self ParseNodeVisitor>>visitBlockNode: aBlockNode aBlockNode statements do: [:statement | statement acceptParseNode: self] Or does such a convention constrain too much how you can extend a visitor pattern? cheers -ben

Nov. 8, 2014

Re: [Pharo-dev] inria survey

by Ben Coman

stepharo wrote: > Hi guys > > you can help us to improve our communication as a research center. > Please take some minutes to fill this little survey. > > Stef > > ---------------------------------- > VERSION FRANÃAISE > ---------------------------------- > CrÃ©Ã© depuis 2002 Ã Lille, le centre de recherche Inria Lille - Nord > Europe souhaite faire un point dâÃ©tape sur sa notoriÃ©tÃ© et sâinterroge > sur lâimage quâil vÃ©hicule auprÃ¨s des diffÃ©rents publics avec lesquels > il collabore. Industriels, partenaires acadÃ©miques, collectivitÃ©s, > chercheurs, journalistes, fournisseurs, Ã©tudiants, lycÃ©ensâ¦ Nous voulons > savoir si vous nous connaissez bien et si vous auriez envie dâen savoir > plus. Vos avis nous intÃ©ressent alors nâhÃ©sitez pas Ã complÃ©ter le > questionnaire avant le 28 novembre. > > David Simplot-Ryl directeur Inria Lille - Nord Europe > > > En pratique ; > Lien vers le questionnaire : > https://sondages.inria.fr/index.php/632788?lang=fr > ClÃ´ture de lâenquÃªte le 28 novembre. > Temps de rÃ©ponse au questionnaire : moins de 10min. > Les rÃ©sultats de lâenquÃªte seront communiquÃ©s en 2015. > > http://www.inria.fr/centre/lille/actualites/enquete-sur-l-image-du-centre-i… > > > -------------------------------- > ENGLISH VERSION > -------------------------------- > Created since 2002 in Lille, the Inria Lille - Nord Europe research > center wish to make a report on its reputation and its image. Industrial > and academic partners, researchers, journalists , suppliers, > students,... We want to know if you know us well and if you would like > to learn more. We are interested in your opinion then do not hesitate to > complete the questionnaire before 28 November. David Simplot- Ryl > director Inria Lille - Nord Europe > > David Simplot-Ryl director Inria Lille - Nord Europe > > In practice ; > Link to the survey :https://sondages.inria.fr/index.php/632788?lang=fr > (select English) > Deadline to respond 28 November. > Questionnaire response time : less than 10 minutes. > The results of the survey will be released in 2015. > > http://www.inria.fr/en/centre/lille/news/inria-lille-nord-europe-survey > > I've completed it, but some ambiguities I encountered... What is "Vulgarization of science" ? For "Patient specific model" is this specifically referring to a medical application, or a translation error meaning "User" specific model? btw, it would have been nice to be able to go back to previous pages. cheers -ben

Nov. 8, 2014

Re: [Pharo-dev] NAtiveBoost error

by Alain Rastoul

Le 07/11/2014 21:11, stepharo a Ã©crit : > > 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 ;) > Avec plaisir :) But to be honest, I am very disappointed with zeroMQ library, not what I was expecting reading docs and books (some hype, not only sure but some), lots of asserts in code like unlikely(condition), return code tests not clear, looks very fragile, breakable and somewhat uncertain (and often crashed). In fact about the linux problem, I suspect (really not sure yet) a side effect with the pharo vm signals, that should not be the case for a library. Reading some posts and answers about python interfacing problems, I think ZeroMQ works well in a program that is designed to use it and only. It may work well with other systems, but not designed in that mindset (assertions in posts like : failing here must abort the program?!). Things that make me think that zeroMQ is probably not a reliable thing to use in Pharo. Plus the only answer I had on the mq list was my own answer (or comment) on debugging the library :( BTW, I have the websocket B plan for that (first tests make me think it could be a better plan for my needs). It will be a different animal, but interesting too. >> >> 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