- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] context mirror primitives

by Esteban A. Maringolo

Thank you Doru! When do you guess it is going to be integrated in the main codebase? Esteban A. Maringolo 2016-01-04 12:42 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > The VM (both Cog and Spur) supports basic manipulation of objects without relying on sending messages to those objects. These primitives are meant to be handled by methods in Context. Eliot provided a changeset with these methods, and they are not yet in Pharo: > > object: anObject basicAt: index > object: anObject basicAt: index put: value > object: anObject eqeq: anOtherObject > object: anObject instVarAt: anIndex > object: anObject instVarAt: anIndex put: aValue > object: anObject perform: selector withArguments: argArray inClass: lookupClass > objectClass: anObject > objectSize: anObject > > I added an issue and the slice: > https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context > > As I note in the issue, I think it is certainly interesting to have a more powerful mirrors mechanism, but until then we should still be able to use what the VM already provides. > > I would like to use these primitives now to make the GT Inspector and Debugger be able to work with ProtoObject. I thought these methods were supposed to be in the Spur version of Pharo, but it seems they are not. So, I am wondering if maybe I am not missing something. Am I missing something or should we integrate these methods? > > Cheers, > Doru > > -- > www.tudorgirba.com > www.feenk.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > > >

Jan. 4, 2016

Re: [Pharo-dev] context mirror primitives

by Tudor Girba

Hi, > On Jan 4, 2016, at 6:30 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hello, > > This is unrelated to Spur / SqueakV3 memory manager. The VM support has been there and stable for a long time now. > > I tried to add those primitives in Pharo but the problem is that the debugger in Pharo uses EyeInspector whereas the inspectors are done with Glamour. > > Hence, to add support for ProtoObject debugging you need: > - to make interpretation implemented in Context compliant > - to make EyeInspector compliant (for the inspector in the debugger) > - to make GTInspector compliant. I am not sure I understand what you mean by " interpretation implemented in Context compliantâ. Could you explain? I already made GTInspector and GTDebugger work with ProtoObject once. I lost the changes in the meantime :), but I will redo them. The only thing I needed were these primitives. But, maybe I missed something. Cheers, Doru > Cheers ! > > Clement > > > 2016-01-04 16:42 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > The VM (both Cog and Spur) supports basic manipulation of objects without relying on sending messages to those objects. These primitives are meant to be handled by methods in Context. Eliot provided a changeset with these methods, and they are not yet in Pharo: > > object: anObject basicAt: index > object: anObject basicAt: index put: value > object: anObject eqeq: anOtherObject > object: anObject instVarAt: anIndex > object: anObject instVarAt: anIndex put: aValue > object: anObject perform: selector withArguments: argArray inClass: lookupClass > objectClass: anObject > objectSize: anObject > > I added an issue and the slice: > https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context > > As I note in the issue, I think it is certainly interesting to have a more powerful mirrors mechanism, but until then we should still be able to use what the VM already provides. > > I would like to use these primitives now to make the GT Inspector and Debugger be able to work with ProtoObject. I thought these methods were supposed to be in the Spur version of Pharo, but it seems they are not. So, I am wondering if maybe I am not missing something. Am I missing something or should we integrate these methods? > > Cheers, > Doru > > -- > www.tudorgirba.com > www.feenk.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > > > > -- www.tudorgirba.com www.feenk.com "Things happen when they happen, not when you talk about them happening."

Jan. 4, 2016

Re: [Pharo-dev] context mirror primitives

by ClÃ©ment Bera

Hello, This is unrelated to Spur / SqueakV3 memory manager. The VM support has been there and stable for a long time now. I tried to add those primitives in Pharo but the problem is that the debugger in Pharo uses EyeInspector whereas the inspectors are done with Glamour. Hence, to add support for ProtoObject debugging you need: - to make interpretation implemented in Context compliant - to make EyeInspector compliant (for the inspector in the debugger) - to make GTInspector compliant. Cheers ! Clement 2016-01-04 16:42 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > The VM (both Cog and Spur) supports basic manipulation of objects without > relying on sending messages to those objects. These primitives are meant to > be handled by methods in Context. Eliot provided a changeset with these > methods, and they are not yet in Pharo: > > object: anObject basicAt: index > object: anObject basicAt: index put: value > object: anObject eqeq: anOtherObject > object: anObject instVarAt: anIndex > object: anObject instVarAt: anIndex put: aValue > object: anObject perform: selector withArguments: argArray inClass: > lookupClass > objectClass: anObject > objectSize: anObject > > I added an issue and the slice: > > https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context > > As I note in the issue, I think it is certainly interesting to have a more > powerful mirrors mechanism, but until then we should still be able to use > what the VM already provides. > > I would like to use these primitives now to make the GT Inspector and > Debugger be able to work with ProtoObject. I thought these methods were > supposed to be in the Spur version of Pharo, but it seems they are not. So, > I am wondering if maybe I am not missing something. Am I missing something > or should we integrate these methods? > > Cheers, > Doru > > -- > www.tudorgirba.com > www.feenk.com > > "Problem solving efficiency grows with the abstractness level of problem > understanding." > > > > > >

Jan. 4, 2016

context mirror primitives

by Tudor Girba

Hi, The VM (both Cog and Spur) supports basic manipulation of objects without relying on sending messages to those objects. These primitives are meant to be handled by methods in Context. Eliot provided a changeset with these methods, and they are not yet in Pharo: object: anObject basicAt: index object: anObject basicAt: index put: value object: anObject eqeq: anOtherObject object: anObject instVarAt: anIndex object: anObject instVarAt: anIndex put: aValue object: anObject perform: selector withArguments: argArray inClass: lookupClass objectClass: anObject objectSize: anObject I added an issue and the slice: https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context As I note in the issue, I think it is certainly interesting to have a more powerful mirrors mechanism, but until then we should still be able to use what the VM already provides. I would like to use these primitives now to make the GT Inspector and Debugger be able to work with ProtoObject. I thought these methods were supposed to be in the Spur version of Pharo, but it seems they are not. So, I am wondering if maybe I am not missing something. Am I missing something or should we integrate these methods? Cheers, Doru -- www.tudorgirba.com www.feenk.com "Problem solving efficiency grows with the abstractness level of problem understanding."

Jan. 4, 2016

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Tudor Girba

Thank you, Sven! I like this very much. This would also mean that we could deprecate Collection>>#sum altogether :)) Cheers, Doru > On Dec 30, 2015, at 12:53 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Henrik, > >> On 25 Dec 2015, at 14:08, Henrik Nergaard <henrin10(a)student.uia.no> wrote: >> >> Like this? >> http://smalltalkhub.com/#!/~Latsabben/NumIt > > That is a cool take on a possible approach. Thanks for doing it, it makes it much easier to think about and discuss alternatives. > > This inspired me to do something similar, but not quite. I am just thinking out loud by implementation. Here is my result: > > <Collections-Operations-SvenVanCaekenberghe.1.mcz> > > There are some examples in the class comments. > > Sven > >> Best regards, >> Henrik >> >> -----Original Message----- >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of stepharo >> Sent: Thursday, December 24, 2015 9:58 AM >> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers: >> >> Just a remark. >> I think that we discarded the proposition of having >> >> aCol arithmetic sum >> >> but I found it nice because there if was clear that you want to get back >> 0 for #(). >> >> Stef >> > -- www.tudorgirba.com www.feenk.com "Innovation comes in the least expected form. That is, if it is expected, it already happened."

Jan. 4, 2016

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Guillermo Polito

I like these last. Particularly because - it cleans the collectionâs API - we can continue extending this idea to add parallelism, mutual exclusion... > On 29 dic 2015, at 11:53 p.m., Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Henrik, > >> On 25 Dec 2015, at 14:08, Henrik Nergaard <henrin10(a)student.uia.no> wrote: >> >> Like this? >> http://smalltalkhub.com/#!/~Latsabben/NumIt > > That is a cool take on a possible approach. Thanks for doing it, it makes it much easier to think about and discuss alternatives. > > This inspired me to do something similar, but not quite. I am just thinking out loud by implementation. Here is my result: > > <Collections-Operations-SvenVanCaekenberghe.1.mcz> > > There are some examples in the class comments. > > Sven > >> Best regards, >> Henrik >> >> -----Original Message----- >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of stepharo >> Sent: Thursday, December 24, 2015 9:58 AM >> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers: >> >> Just a remark. >> I think that we discarded the proposition of having >> >> aCol arithmetic sum >> >> but I found it nice because there if was clear that you want to get back >> 0 for #(). >> >> Stef >> >

Jan. 4, 2016

do you know we have an issue tracker? (rant)

by Esteban Lorenzano

Hi guys, Soâ¦ last two weeks I was first in Togo with Stef and after taking holidays for the end of the year. During that time some bugs on new FFI emerged and were talked in this listâ¦ Today I came back to work and I wanted to walk through the issues to priorize and start work on fixing themâ¦ and no reports on the issue tracker :( So Iâm forced to do email-archeology to dig up the problemsâ¦ or just ignore them until a report arrives. What is not in the issue tracker does not exist: PLEASE REPORT YOUR ISSUES. thanks, Esteban

Jan. 4, 2016

Re: [Pharo-dev] [Pharo-users] NeoJSON: parsing mapped nil fields

by Skip Lentz

Hi Sven, > On Dec 30, 2015, at 12:51 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I added a new feature: Thank you for this new feature! > From the unit test, this allows you to do as follows: > > self > assert: ((NeoJSONReader on: 'null' readStream) > mapInstVarsFor: Point; > for: Point do: [ :mapping | mapping allowNil ]; > nextAs: Point) > equals: nil. > > self > assert: ((NeoJSONReader on: '[ { "x" : 1, "y" : 2 }, null, { "x" : 3, "y" : -1 } ]' readStream) > mapInstVarsFor: Point; > for: Point do: [ :mapping | mapping allowNil ]; > for: #ArrayOfPoints customDo: [ :mapping | mapping listOfElementSchema: Point ]; > nextAs: #ArrayOfPoints) > equals: { 1 @ 2. nil. 3 @ -1 }. > > I decided to make this a per mapping option, not a per reader option. Maybe there should be an ensureNotNil option too, which sets allowNil to false? This allows for changing it back to the default mode when reusing the same reader. I tried making this a per _property mapping_ option, but it became a bit of a hack so I stopped doing that. > No, that would not help ;-) > > The two approaches are fundamentally different: either you accept anything that is present (dynamic mode), returning lists (Arrays) and maps (Dictionaries), or you accept a schema that is predefined (static mode). > >>> When you use mappings and #nextAs: it tries to map a static type structure on what is coming in. As such it is not really prepared for dynamic surprises like objects being replaced by null. >> >> Yes, in the general case, once youâve sent #nextAs: to the reader with your value schema, youâre âstuckâ with that exact schema. >> >> While working on the bindings for the GitHub API, there are some JSON representations which send a âtypeâ field (e.g. âtypeâ : âcommitâ). >> I would like it to be possible to change the class schema to that of a subclass of the original class when detecting a combination of fields. >> >> That is, I specify a combination of fields, and if any is present, then change the class of the current object to a subclass. By specifying combinations of fields, you don't rely on the order in which they appear in the JSON. >> >> Maybe in this way it is possible to accomplish without giving up the nice property of NeoJSON not making intermediate structures? Sounds tough to do without turning it into a hack though.. > > I know what you mean, there are 2 common approaches (some would call it a wrong way to use JSON, but that is another discussion): > > { "type":"Point", "x":1, "y":2 } > > or > > { "type":"Point", "value": {"x":1, "y":2} } > > (Type could be class, or whatever). > > The first case is bad, you have to read everything before you can make a decision, which IMO kills the advantage of mapping while trying to avoid intermediate structures (i.e. you could do the mapping yourself afterwards). > > The second case is a bit better, but not much. Both top level elements could have switched place, in which case you already have to read the value, not knowing what to map it to. Exactly, this is what I meant. > You could try experimenting with Custom mappings, they allow arbitrary conversions, but I doubt if you could really prevent intermediate structure creation. But maybe I just don't see it right, and it is possible after all. One could perhaps use adoptInstance:, based on some conditions (e.g. âif the json contains this combination of keysâ, âif the type field has the value âcommitââ). But on the other hand this solution would make NeoJSON less simple, and the simplicity of the library is a very nice property. It would be stupid to throw that property away for a solution that doesn't even cover all of the cases. > If the returned JSON is highly dynamic and variable, I would just use dynamic mode and then in a second pass convert the maps/lists to domain objects myself. Or someone should write a generic maps/lists to domain model objects mapper (independent of JSON). Yes this might be the best solution in this case. Best wishes for 2016 :), Skip

Jan. 4, 2016

Need more success stories

by stepharo

Hi I know some of you have really cool success stories and I need one paragraph. Many people are looking at us via the web. So please take 15 min and write such paragraph. Stef

Jan. 3, 2016

Re: [Pharo-dev] Status of GitFileTree in Pharo 5.0 and Spur

by Mariano Martinez Peck

On Sun, Jan 3, 2016 at 1:18 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 03/01/2016 17:11, Alexandre Bergel a Ã©crit : > >> That would be fantastic to have this fixed >> > > Well, that or Mariano's solution :) > > I think we will always need OSProcess around because that gives you a real access to everything since it's at plugin level and because it uses the bare metal of fork + exec combination :) With my solution, you may solve many easy cases, but for other cases, you will very much likely need OSProcess. BTW, I am trying your OSProcess git usage but I must finish a few things for that ;) > Thierry > > > Cheers, >> Alexandre >> >> >> On Jan 3, 2016, at 12:57 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> >>> wrote: >>> >>> >>> >>> On Sun, Jan 3, 2016 at 12:54 PM, Thierry Goubier < >>> thierry.goubier(a)gmail.com> wrote: >>> Le 03/01/2016 16:49, Mariano Martinez Peck a Ã©crit : >>> mmmm ok, I am giving it a try but it seems it's not working or... mostly >>> likely, I am doing something wrong. >>> I just created a repo via github web interface, then I clone it to my >>> machine, and then I tried to add the gitfiletree repo in MC Browser, but >>> I get an error in: #currentBranch because #gitBranchs answered an empty >>> array. But the `git branch` command was really executed as I can see the >>> output of it in the stdout of the VM. So I guess OSProcess stdout >>> setting may be what is not working? >>> >>> You're on Mac when you do that, right? >>> >>> >>> Yep. >>> >>> OSProcess output redirection doesn't work in the latest Mac VM... my >>> fault (introduced in the OSProcess plugin) :( but I have no idea why the fd >>> dup / pipes work on Linux and not on Mac OS X. >>> >>> >>> OSProcess uses (as well as my prototype) dup2 rather than dup. >>> >>> Thierry >>> >>> >>> Thanks in advance, >>> >>> On Sun, Jan 3, 2016 at 12:01 PM, Mariano Martinez Peck >>> <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>> >>> Hi Thierry, >>> >>> I had some problems with OSProcess in 5.0 with Spur so I wonder >>> what's the status with GitFileTree. Is it working with latest 5.0? >>> I tried to search some tests to confirm this but I found none. >>> >>> Thanks in advance, >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> > > -- Mariano http://marianopeck.wordpress.com

Jan. 3, 2016