January 2016 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Version number difference between MC and GitFileTree

by Mariano Martinez Peck

On Sun, Jan 3, 2016 at 1:17 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 03/01/2016 17:04, Mariano Martinez Peck a Ã©crit : > >> Hi Thierry, >> >> When I commit from MC, I see the generated commit, with something >> like OSSubprocess-MarianoMartinezPeck.7. However, when browse the >> repository later from MC, I get that such a commit is displayed >> as OSSubprocess-MarianoMartinezPeck.4 (the rest of the commit message >> maps correctly). >> >> Could this offset be because of the first initial 3 commits? That is, >> initial git commit from github, and 2 commits of "gitfiletree >> repository properties". >> > > This is because Monticello pre-computes a version number without asking > the repository about it... And GitFileTree disregard that version number > (the 'filetree' metadata) and recomputes a version number from the git log > history. > > Is there a workaround here so that both could map correctly? >> > > Yes. The latest Pharo5.0 development version of GitFileTree does a become > to force Monticello to refer to the git saved version afterwards. OK, something is something!! > But... > > 1- The GUI still shows the MC-computed version not the git one :( > > 2- The package copy stored into package-cache is at the MC version and not > the git one. > > Maybe there is something to consider there about the model behind > Monticello when doing all those operations, especially 2-. At the moment, > MC behaves like the package-cache has priority on the specifics of the real > repository you are saving to :( > > you need a brave soul for that task hahahaha! I guess I will give it a try to bleeding edge then. BTW...if you ever happen to fix any of those points please let me know! pd: damn, you #pwd: usage of OSProcess made me another complicated issue to solve via FFI hahahahah -- Mariano http://marianopeck.wordpress.com

Jan. 3, 2016

Re: [Pharo-dev] Version number difference between MC and GitFileTree

by Mariano Martinez Peck

On Sun, Jan 3, 2016 at 1:12 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Yes, there is a version number mismatch. But I do not feel this is that > important. On some point, version number should be extracted from Git > metadata, and not from a simple counter. > > Well, I does confuses me, because the idea of GitFileTree is to integrate git into the image. So if I browse with MC and that does not match at all what I committed via MC itself too, then that is confusing. At least for me. For that a case, I would prefer to commit , push, pull etc everything by hand and that would be clearer. > By the way, what is a âsubprocessâ? > > It's name I gave to the project I started (the one I send the survey), it's called (at least so far) OSSubprocess. This is easy because one can think it's quite close to OSProcess (which is true). It seems Python does have similar names: https://docs.python.org/2/library/subprocess.html If you have a better name I am all ears :) Alexandre > > > > On Jan 3, 2016, at 1:04 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > Hi Thierry, > > > > When I commit from MC, I see the generated commit, with something like > OSSubprocess-MarianoMartinezPeck.7. However, when browse the repository > later from MC, I get that such a commit is displayed as > OSSubprocess-MarianoMartinezPeck.4 (the rest of the commit message maps > correctly). > > > > Could this offset be because of the first initial 3 commits? That is, > initial git commit from github, and 2 commits of "gitfiletree repository > properties". > > > > Is there a workaround here so that both could map correctly? > > > > Thanks in advance, > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- Mariano http://marianopeck.wordpress.com

Jan. 3, 2016

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

by David T. Lewis

On Sun, Jan 03, 2016 at 04:54:48PM +0100, Thierry Goubier 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? > > 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. Hi Thierry, I cannot say if it is related to the problem you are discussing here for Mac VMs, but I should mention that there is an error in the oscog branch of OSProcessPlugin (the one that you are using for Pharo VMs). The following test passes in the main branch of OSPP but fails for oscog version: (UnixProcessAccessorTestCase selector: #testRedirectStdOutTo) run If you are compiling your own VM, you may want to try using the main branch of OSPP (VMConstruction-Plugins-OSProcessPlugin-dtl.40) rather than the oscog version (VMConstruction-Plugins-OSProcessPlugin.oscog-eem.50) and see if it makes a difference. Dave

Jan. 3, 2016

Re: [Pharo-dev] Version number difference between MC and GitFileTree

by Thierry Goubier

Le 03/01/2016 17:12, Alexandre Bergel a Ã©crit : > Yes, there is a version number mismatch. But I do not feel this is > that important. On some point, version number should be extracted > from Git metadata, and not from a simple counter. I'm solving that (forcing a become to replace the MC version info by the new git generated version info... but the GUI isn't updated). If someone is interested to have a look at refactoring the underlying Monticello model of versions and repositories and caches and ... ;) Thierry > By the way, what is a âsubprocessâ? > > Alexandre > > >> On Jan 3, 2016, at 1:04 PM, Mariano Martinez Peck >> <marianopeck(a)gmail.com> wrote: >> >> Hi Thierry, >> >> When I commit from MC, I see the generated commit, with something >> like OSSubprocess-MarianoMartinezPeck.7. However, when browse the >> repository later from MC, I get that such a commit is displayed as >> OSSubprocess-MarianoMartinezPeck.4 (the rest of the commit message >> maps correctly). >> >> Could this offset be because of the first initial 3 commits? That >> is, initial git commit from github, and 2 commits of "gitfiletree >> repository properties". >> >> Is there a workaround here so that both could map correctly? >> >> Thanks in advance, >> >> -- Mariano http://marianopeck.wordpress.com >

Jan. 3, 2016

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

by Thierry Goubier

Le 03/01/2016 17:11, Alexandre Bergel a Ã©crit : > That would be fantastic to have this fixed Well, that or Mariano's solution :) 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 >

Jan. 3, 2016