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

All-you-can-eat JSON

by Sean P. DeNigris

There is: 1. http://smalltalkhub.com/#!/~NicolasPetton/JSON 2. http://smalltalkhub.com/#!/~PharoExtras/JSON, and 3. http://smalltalkhub.com/#!/~abergel/JSON It seems like #1 and #2 (which adds a MetaC config and one additional package update) are trying to do the same thing, and maybe #3, which is described as "Adapted for parsing very large files" can also be merged. Right now, things are a bit confusing. How best to proceed? ----- Cheers, Sean -- View this message in context: http://forum.world.st/All-you-can-eat-JSON-tp4774925.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 26, 2014

Re: [Pharo-dev] [Moose-dev] [ANN] Voronyj Diagram

by Damien Pollet

On 26 August 2014 15:23, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Can you share what is necessary to reproduce the pictures youâve sent ? (e.g., PoissonDiscDistribution class) sure: Gofer new smalltalkhubUser: 'cdlm' project: 'Flatland'; package: 'PoissonDiscSampler'; load -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 26, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40187 Home: https://github.com/pharo-project/pharo-core

Aug. 26, 2014

[pharo-project/pharo-core] 5cc4c3: 40187

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 5cc4c32917dc48af0f0366414eaa7d8f4f030d34 https://github.com/pharo-project/pharo-core/commit/5cc4c32917dc48af0f036641… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-08-26 (Tue, 26 Aug 2014) Changed paths: M Polymorph-Widgets.package/ExpanderMorph.class/instance/operations/titleText_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script187.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40187.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40187 13566 should remove this kind of isKindOf: https://pharo.fogbugz.com/f/cases/13566 http://files.pharo.org/image/40/40187.zip

Aug. 26, 2014

Re: [Pharo-dev] [Moose-dev] [ANN] Voronyj Diagram

by Alexandre Bergel

Hi Damien, Can you share what is necessary to reproduce the pictures youâve sent ? (e.g., PoissonDiscDistribution class) Alexandre On Aug 25, 2014, at 9:38 PM, Damien Pollet <damien.pollet(a)gmail.com> wrote: > Hi Natalia, > > I've been playing with it today, and look at the pretty pixels it makes :D > The points are generated by the poisson disc sampling algorithm > described at http://bost.ocks.org/mike/algorithms/ > > However, see the result of the doit, in redâ¦ the time grows really > quick with the number of nodes, which makes it impractical with large > point sets (the 2 smaller sets are instant, the 3rd one quickly pops > the progress bar, and the 4th takes a couple minutes). Wikipedia says > the complexity should be around N log N, so that's strange ; I've seen > the code copies collections a lot, that might be itâ¦ but it's too late > for coding now :| > > On 25 July 2014 19:12, Natalia Tymchuk <natalia.tymchuk(a)unikernel.net> wrote: >> Thank you. >> Yes, I will. >> >> Natalia >> >> On Jul 25, 2014, at 5:36 PM, Alexandre Bergel <alexandre.bergel(a)me.com> >> wrote: >> >> Impressive!!!! >> >> Natalia, will you be at esug? >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> On Jul 25, 2014, at 8:10 AM, Natalia Tymchuk <natalia.tymchuk(a)unikernel.net> >> wrote: >> >> Hello. >> >> I implemented Voronyj diagrams for Roassal. You can read about it here: >> http://natalia.tymchuk.me/RTVoronyjDiagram/ . >> I will be on vacation from Monday till Thursday, but it will be really cool >> if you can write me your opinion about this project and all your remarks. >> >> Best regards, >> Natalia >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > <Poisson + Voronyj.png> -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 26, 2014

Re: [Pharo-dev] [Moose-dev] [ANN] Voronyj Diagram

by Emilio Oca

Hi Natalia, I think Damien is right, you should consider Fortune algorithm (http://en.wikipedia.org/wiki/Fortune%27s_algorithm) As seen in this image http://upload.wikimedia.org/wikipedia/commons/0/0c/Fortunes-algorithm-slowe… when the sweep line advances, it generates different events that allows you build auxiliary structures like the polygons you need. Usually you are able to end the Voronyj construction and all the related structures in n log n, with n the number of sites. Best Emilio > -----Mensaje original----- > De: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] En nombre de > Damien Pollet > Enviado el: Martes, 26 de Agosto de 2014 07:03 > Para: Pharo Development List > CC: Moose-related development > Asunto: Re: [Pharo-dev] [Moose-dev] [ANN] Voronyj Diagram > > On 26 August 2014 09:29, Natalia Tymchuk <natalia.tymchuk(a)unikernel.net> > wrote: > > It is the reason, however I wanted not only draw the diagram as a lot > of segments, but to build the polygons and for that I need all that > collections. > > It's not a matter of having many collections, but of repeatedly making > copies in nested loops. For instance, in uniqueTriCombiDo: using > allButFirst: followed by withIndexDo: can be replaced by to:do: > > However, I guess the biggest gain would be in avoiding to enumerate > potential triangles over the whole point set, since that's > combinatorial; for instance > http://en.wikipedia.org/wiki/Fortune%27s_algorithm > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 26, 2014

Re: [Pharo-dev] Failing make a slice

by Sven Van Caekenberghe

I tried to make a new slice, can you see if it works for you (i.e. contains your changes) ? On 25 Aug 2014, at 19:26, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > Hi, > > I have failed to make new slice for this issue: https://pharo.fogbugz.com/f/cases/13185/Move-embedded-fonts-from-Freetype-p… > > The last slice I have made depends on packages which has the same name but different UUID. > > How can I fix this? The issue should depend on FreeType-JurajKubelka.677, EmbeddedFreeType-JurajKubelka.3, EmbeddedFreeTypeTests-JurajKubelka.2. > > Thanks, > Juraj

Aug. 26, 2014

Re: [Pharo-dev] Roadmap on tools?

by phil＠highoctane.be

On Tue, Aug 26, 2014 at 12:53 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > If Benjamin does not intend to continue developing in Pharo , that means > he will not continue developing Spec. So in any case you need to talk to > him and see exactly what his intentions are. > > But if he does not want to let us use it as integrated library for Pharo > then I don't think you guys have much of a choice. One thing to remember > here is that licenses extend to modification and extensions, that means > that anyone who makes an extension to Spec or a Spec based app cannot > integrate it to Pharo so already Pharo tools using Spec are against the > dual license. Personally I would not use such library for my projects > because I do care integrating some of my code back to Pharo to contribute > to the progress of Pharo. > Spec has been developed under MIT. From there, before the license change, we can fork and do whatever we want. Furthermore, contributors have signed a paper. And Ben has been publishing papers etc, under a budget. So, we can fork and change what we need to. What we cannot do is take the new stuff Ben would do. But as you say, this looks like a dead end anyway. What the heck, we can take Spec from where it is now, this is a core Pharo asset, and make it work and grow, it is not like this tool is done by the way, far from it. And Spec is not Morphic only, it is for all kinds of rendering backends (Seaside, Morphic, Bloc maybe). Phil > > > On Tue, Aug 26, 2014 at 1:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> >> On 26 Aug 2014, at 11:50, phil(a)highoctane.be wrote: >> >> > On Tue, Aug 26, 2014 at 11:42 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> > >> > On 26 Aug 2014, at 11:22, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> > >> > > >> > > On 26 Aug 2014, at 10:58, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> > > >> > >> There is another option: work together again. >> > > >> > > Is an option, in theory. But doesnât looks like happening any time >> soon, sadly :( >> > >> > Well, everybody loses by forking. >> > >> > Sure but for Ben new commits will be GPL. Pull requests included. >> > Basically, we are fucked on that line I'd say. >> >> @Phil >> >> Look, I don't want to defend or attack either party and the recent >> license change is a bit dubious, like Marcus said. But for the sake of >> argument, I think your conclusion is wrong: he says/wants Spec to be >> managed as an external library that gets integrated back to Pharo from time >> to time. When doing so, everything remains MIT licensed. Else he wants it >> to be GPL-ed so that it cannot be integrated in Pharo. >> >> @Esteban >> >> But again: if there is a conflict there are always two solutions, solve >> it or part ways. Saying the other party made me do it is the same as saying >> I am right and he is wrong (and this goes for both sides ;-) >> >> Maybe we should start another thread about this. Because the basic >> question is not about a license or a name change but about how to work >> together and about control, specifically for parts and/or developers that >> are external. I know that this is a complex discussion, but if we in >> general have problems of working modular than we are in trouble, no ? >> >> Sven >> >> >> >

Aug. 26, 2014

Re: [Pharo-dev] Roadmap on tools?

by kilon alios

If Benjamin does not intend to continue developing in Pharo , that means he will not continue developing Spec. So in any case you need to talk to him and see exactly what his intentions are. But if he does not want to let us use it as integrated library for Pharo then I don't think you guys have much of a choice. One thing to remember here is that licenses extend to modification and extensions, that means that anyone who makes an extension to Spec or a Spec based app cannot integrate it to Pharo so already Pharo tools using Spec are against the dual license. Personally I would not use such library for my projects because I do care integrating some of my code back to Pharo to contribute to the progress of Pharo. On Tue, Aug 26, 2014 at 1:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 26 Aug 2014, at 11:50, phil(a)highoctane.be wrote: > > > On Tue, Aug 26, 2014 at 11:42 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > On 26 Aug 2014, at 11:22, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > > > > > On 26 Aug 2014, at 10:58, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > >> There is another option: work together again. > > > > > > Is an option, in theory. But doesnât looks like happening any time > soon, sadly :( > > > > Well, everybody loses by forking. > > > > Sure but for Ben new commits will be GPL. Pull requests included. > > Basically, we are fucked on that line I'd say. > > @Phil > > Look, I don't want to defend or attack either party and the recent license > change is a bit dubious, like Marcus said. But for the sake of argument, I > think your conclusion is wrong: he says/wants Spec to be managed as an > external library that gets integrated back to Pharo from time to time. When > doing so, everything remains MIT licensed. Else he wants it to be GPL-ed so > that it cannot be integrated in Pharo. > > @Esteban > > But again: if there is a conflict there are always two solutions, solve it > or part ways. Saying the other party made me do it is the same as saying I > am right and he is wrong (and this goes for both sides ;-) > > Maybe we should start another thread about this. Because the basic > question is not about a license or a name change but about how to work > together and about control, specifically for parts and/or developers that > are external. I know that this is a complex discussion, but if we in > general have problems of working modular than we are in trouble, no ? > > Sven > > >

Aug. 26, 2014

Re: [Pharo-dev] Roadmap on tools?

by Sven Van Caekenberghe

On 26 Aug 2014, at 11:50, phil(a)highoctane.be wrote: > On Tue, Aug 26, 2014 at 11:42 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 26 Aug 2014, at 11:22, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > > On 26 Aug 2014, at 10:58, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> There is another option: work together again. > > > > Is an option, in theory. But doesnât looks like happening any time soon, sadly :( > > Well, everybody loses by forking. > > Sure but for Ben new commits will be GPL. Pull requests included. > Basically, we are fucked on that line I'd say. @Phil Look, I don't want to defend or attack either party and the recent license change is a bit dubious, like Marcus said. But for the sake of argument, I think your conclusion is wrong: he says/wants Spec to be managed as an external library that gets integrated back to Pharo from time to time. When doing so, everything remains MIT licensed. Else he wants it to be GPL-ed so that it cannot be integrated in Pharo. @Esteban But again: if there is a conflict there are always two solutions, solve it or part ways. Saying the other party made me do it is the same as saying I am right and he is wrong (and this goes for both sides ;-) Maybe we should start another thread about this. Because the basic question is not about a license or a name change but about how to work together and about control, specifically for parts and/or developers that are external. I know that this is a complex discussion, but if we in general have problems of working modular than we are in trouble, no ? Sven

Aug. 26, 2014