October 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About Magritte Seaside

by stepharo

> >> I think that this is only true for packages committed within the same >> repo. >> Now between porjects published in different repo you have to express >> them. >> I do not think that we all want to publish in the same repo and clone >> out everything. > ... and inter-project dependencies is what a BaselineOf does .... > which brings me back to the conclusion that I reached when I scanned > the paper:) Yes probably but you have to have a BaselineOf for every package. Because we want to have the dependency expressed in every package and not in a gigantic "project" configuration of. >> >> When a package is released into the market: then it externalise its >> metadata so that a crawler can automatically build >> dependency graph and create specific distribution. > Okay. This is a problem .... but it happens to be a problem that > Metacello "can solve/does solve" - so there must be something else (a > deeper problem?) that I don't quite understand. But you have to load the configuration and somehow execute it so that it computes the dependencies and we do not want. > With that said, if you are planning to replace Metacello, then I am > excited:) But I will repeat that I hope that you are considering cross > platform issues ... Yes we do. First we wanted to make it work. Then we should have kind of virtual packages that act as platforms or project level > Perhaps at this point in time, I'd like to read some code. Then I can > skip reading the paper and get a feel for how hard it will be to port > to GemStone:) I do not know where christophe save his code but it is be public. > > Dale > >

Oct. 11, 2015

Re: [Pharo-dev] hash and Collections. A solution for some.

by Ralph Boland

I haven't followed this thread closely so I apologize in advance if I am somewhat off topic but I think what I have to say may be of interest to some of you. I think the current method of determining a hash value for a collection is fine in the general case and if it is inadequate for your particular needs then implement your own collection class that does what you want. This was the case for one of my applications so I created classes HashArray and HashSet. Both of these classes used as their hash value the XOR of the the hash values of the collection elements (which was of course stored in an instance variable). Each time an element was added, removed, or replaced in the collection the hash value of the collection had to be recomputed (required O(1) time). Of course this approach breaks down if the collection elements can change their hash values. My solution is not ideal for the hashArray case because two hashArrays containing the same elements but in a different order would have the same hash value. But this didn't matter for my application because I used hashArrays as a set converted into an array (with values sorted) for time/space efficiency reasons. This worked really well for me, in part because the elements stored in the hashArrays and hashSets also had really good hash values. Also note that, in my application, two hashArrays or hashSets containing the same elements were considered to be equal. If anyone makes use of this idea I wouldn't mind a quick email on your experience. Ralph Boland

Oct. 11, 2015

Re: [Pharo-dev] About Magritte Seaside

by Dale Henrichs

On 10/11/15 12:19 AM, stepharo wrote: > > > Le 11/10/15 00:40, Dale Henrichs a Ã©crit : >> Christophe, >> >> I still don't have a lot of time to read the paper and try to >> understand what you are trying to accomplish, > you should read it. :) > We wrote it for that and it is not boring nor long. I scanned through it at the time and as I recall, I thought that the functionality described was already covered by git and BaselineOf ... but I did not read it in great detail and I did not (and still don't) have the time to compose a long-winded response:) > >> but I am curious how you think "package dependencies" will play with >> git-based projects? >> >> In git-based repositories I don't think you have the same type of >> dependency issues that one might have with monticello repositories >> --- In a monticello repository you have a whole range of possible >> package versions to pick from, but in a git-based repository the >> range of package versions is fixed to those that are committed >> together so the packages that are meant to work together are >> committed together. > > I think that this is only true for packages committed within the same > repo. > Now between porjects published in different repo you have to express > them. > I do not think that we all want to publish in the same repo and clone > out everything. ... and inter-project dependencies is what a BaselineOf does .... which brings me back to the conclusion that I reached when I scanned the paper:) >> >> In the bootstrap scenario, you would only have one version per >> package to choose from, so the packages that are meant to work >> together are committed together .... >> >> I guess I don't know what you mean when you say: >>> we want to decouple a released version of a package from the working >>> copy of the package version description (implies the creation of a >>> package repository + a web interface on top of it to promote/search >>> packages). >> Perhaps a description of the problem being solved would help me >> understand. > We want to be able to have a package market place where tools can grab > dependencies without to load code > and can compute the set of packages that should be loaded. > > When a package is released into the market: then it externalise its > metadata so that a crawler can automatically build > dependency graph and create specific distribution. Okay. This is a problem .... but it happens to be a problem that Metacello "can solve/does solve" - so there must be something else (a deeper problem?) that I don't quite understand. With that said, if you are planning to replace Metacello, then I am excited:) But I will repeat that I hope that you are considering cross platform issues ... Perhaps at this point in time, I'd like to read some code. Then I can skip reading the paper and get a feel for how hard it will be to port to GemStone:) Dale

Oct. 11, 2015

Re: [Pharo-dev] A really cool thread on fog bug

by Ben Coman

Glad to help. cheers -ben On Sun, Oct 11, 2015 at 4:58 PM, stepharo <stepharo(a)free.fr> wrote: > https://pharo.fogbugz.com/f/cases/16577/Random-should-be-in-its-own-package > > I love the spirit of this thread!!! > Thank you for this example of collaboration. > > > I wrote : > > I want to **really** thank you. > This thread is great and show the power of collaboration. > We all stronger and better. > Thanks again. >

Oct. 11, 2015

Re: [Pharo-dev] hash and Collections

by monty

The issue: https://pharo.fogbugz.com/f/cases/16760/Dictionary-breaks-when-comparing-id… > Sent: Sunday, October 11, 2015 at 7:23 AM > From: monty <monty2(a)programmer.net> > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] hash and Collections > > Resending because the last was HTML'd: > > Never use #newFrom: with associations from another dictonary if you reuse the first after. > Â > The bug is actually deeper than you know: > dic1 := Dictionary newFrom:{'test' -> 4}. > dic2 := IdentityDictionary newFrom: {'test' copy -> 4}. > dic1 = dic2. > dic2 = dic1. > Â > Depending on the order, they are equal or inequal. > Â > The bug is caused by Dictionary>>= using a polymorphic type test #isDictionary. Squeak is unaffected: its #= uses a hardcoded class == test. The least disruptive fix I can think of is adding another type test #isIdentityDictionary in Dictionary that returns false but returns true for every identity dictionary class (like SmalllIdentityDictionary). Then only compare the associations if "self isIdentityDictionary = aDictionary isIdentityDictionary". > Â > I will open an issue. > >

Oct. 11, 2015

Re: [Pharo-dev] hash and Collections

by monty

Resending because the last was HTML'd: Never use #newFrom: with associations from another dictonary if you reuse the first after. Â The bug is actually deeper than you know: dic1 := Dictionary newFrom:{'test' -> 4}. dic2 := IdentityDictionary newFrom: {'test' copy -> 4}. dic1 = dic2. dic2 = dic1. Â Depending on the order, they are equal or inequal. Â The bug is caused by Dictionary>>= using a polymorphic type test #isDictionary. Squeak is unaffected: its #= uses a hardcoded class == test. The least disruptive fix I can think of is adding another type test #isIdentityDictionary in Dictionary that returns false but returns true for every identity dictionary class (like SmalllIdentityDictionary). Then only compare the associations if "self isIdentityDictionary = aDictionary isIdentityDictionary". Â I will open an issue.

Oct. 11, 2015

Re: [Pharo-dev] hash and Collections

by monty

Oct. 11, 2015

Re: [Pharo-dev] [Slots] Slides from ESUG: Variables in Pharo5

by serge.stinckwich＠gmail.com

Thank you Marcus. This was not urgent matter for me ;-) I don't remember if I give the slides. Please ping me if they are missing. Sent from my iPhone > On 11 oct. 2015, at 11:21, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 11 Oct 2015, at 09:36, serge.stinckwich(a)gmail.com wrote: >> >> Great job Marcus ! >> I could not the SciSmalltalk talk. This was maybe not recorded ? > > Yes, I am missing SciSmalltalk and Block. But I do have some more videos > to go through (not many and they are supposed to be from tuesday afternoon). > > I am now going through the talks one by one from the startâ¦ doing all the small > stuff (converting slides to pdf, upload slideshare, check if video existsâ¦) > > Monday looks already good. > > Marcus > >

Oct. 11, 2015

Re: [Pharo-dev] [Slots] Slides from ESUG: Variables in Pharo5

by Marcus Denker

> On 11 Oct 2015, at 09:36, serge.stinckwich(a)gmail.com wrote: > > Great job Marcus ! > I could not the SciSmalltalk talk. This was maybe not recorded ? Yes, I am missing SciSmalltalk and Block. But I do have some more videos to go through (not many and they are supposed to be from tuesday afternoon). I am now going through the talks one by one from the startâ¦ doing all the small stuff (converting slides to pdf, upload slideshare, check if video existsâ¦) Monday looks already good. Marcus

Oct. 11, 2015

A really cool thread on fog bug

by stepharo

https://pharo.fogbugz.com/f/cases/16577/Random-should-be-in-its-own-package I love the spirit of this thread!!! Thank you for this example of collaboration. I wrote : I want to **really** thank you. This thread is great and show the power of collaboration. We all stronger and better. Thanks again.

Oct. 11, 2015