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

[Pharo-project] pharo-2.0-tests Â» win - Build # 425 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Oct. 20, 2012

[Pharo-project] [update 2.0] #20352

by Marcus Denker

20352 ----- Issue 6834: Failing test: ReleaseTest>>testUnpackagedClasses http://code.google.com/p/pharo/issues/detail?id=6834 Issue 6847: More Error handling Documentation http://code.google.com/p/pharo/issues/detail?id=6847 Issue 6825: Nautilus code uses Symbol readFromString: http://code.google.com/p/pharo/issues/detail?id=6825 Diff information: http://ss3.gemstone.com/ss/Pharo20/RPackage-SystemIntegration-MarcusDenker.… http://ss3.gemstone.com/ss/Pharo20/RPackage-Core-MarcusDenker.194.diff http://ss3.gemstone.com/ss/Pharo20/NautilusCommon-MarcusDenker.99.diff http://ss3.gemstone.com/ss/Pharo20/Nautilus-MarcusDenker.372.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1217.diff -- Marcus Denker -- http://marcusdenker.de

Oct. 20, 2012

Re: [Pharo-project] Yet another Notation format: Object literals

by Frank Shearar

On 20 October 2012 04:13, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 20 October 2012 03:48, Dale Henrichs <dhenrich(a)vmware.com> wrote: >> >> >> ----- Original Message ----- >> | From: "Igor Stasenko" <siguctua(a)gmail.com> >> | To: Pharo-project(a)lists.gforge.inria.fr >> | Sent: Friday, October 19, 2012 4:46:47 PM >> | Subject: Re: [Pharo-project] Yet another Notation format: Object literals >> | >> | On 20 October 2012 00:54, Dale Henrichs <dhenrich(a)vmware.com> wrote: >> | > Igor, >> | > >> | > It's not clear that I need to be part of this discussion. >> | > >> | > If you want to invent a new serialization format, then go for it. >> | > >> | > I did chime in with my opinion that your suggested format was not >> | > very readable. You happen to disagree with me. >> | > >> | >> | Yes, i disagree. Tell me what is not readable in this: >> | >> | #( Dictionary >> | >> | yellow (Color 1 1 0) >> | blue (Color 0 0 1) >> | red (Color 1 0 0) >> | >> | ) fromObjectLiteral. >> >> Please read my earlier description of why I think JSON is more readable as you haven't addressed the main points with this format... > > yes, because i do not regarding them as significant. > >> | >> | this is human-written object literal. It took me very little effort >> | to >> | express correctly the data structure i need to get out of it, with >> | little chance of doing some syntax mistake. >> | For smalltalker, like me, i find this expression is natural and >> | straightforward to read. >> >> I understand that you can read this format, but I still maintain that in the end the lack of a few syntactic elements make this format ambiguous to read/write for the human...You need to full expression to make sense of it though. >> >> It is not the fact that the expression works evaluates correctly but the fact that the interpretation of all of the elements relies upon knowledge of the underlying implementation ... for example, I am not familiar with the Color class so: >> >> (Color 1 1 0) >> >> tells me nothing when I read it ... are those rgb values cyn or some other encoding the lack of the names causes me problems .... if the shape of the Color class changes, then this particular expression will be useless ... in the wild classes tend to change shape over time ... >> > > But this is what conventions for (and conversions written to conform > with conventions). > I do not see a big problem here. > Second, (and that's one of the reasons for not implementing generic > Object>>asObjectLiteral), > you can allow conversion only for certain set of classes, Point, > Number, Collection(s) etc, i.e. the ones > which has ~0 chance of changing shape/representation. > Like in case of dictionary, we do not reflecting the shape of this > class directly i.e. (tally and array ivars), > but rather reflecting its data-structure, so internal representation > is not very important there and hence ca be made highly portable > across dialects. > > Third, if you are not familiar with Color , as long as you won't start > using it in some of your project(s), > i cannot see what should happen to make (Color 1 0 0) appear in the > data what you dealing with in your projects. > From other side, for other person(s) it could be very important for > them to be able to serialize colors. So they will be using it , but in > their own project(s). Now since you never cross roads, i do not see > how you can have any issues with that: it is not your data, therefore > not your headache. > > Fourth, take CSS , for example. they having three ways defining color: > #rrggbb > #rgb > or > rgb(r,g,b) > > and same thing, as you may guess #75927 notation means nothing for > somebody who not familiar with CSS. (he may also make a wild guess, > maybe it is cyn? who knows.. ;) ) > > So, if you don't like (Color 1 0 0) > nothing prevents you from denoting colors in more explicit way, like: > (RGBColor 1 0 0) > or > (RGB 1 0 0) > or > (Color r 1 g 0 b 0 alpha 0) > or whatever you see fit. > > In this notation use of class names is just a cheap and fast way to > for denoting the stored object. > With some little code, you can use arbitrary "type name" for denoting > that, it is just your responsibility to recognize it > and represent it with proper object at the end. But notation form > don't needs to be altered, is will still stay > (<data type name> <values>) > and still smalltalk syntax. > > >> | >> | And do not discount the environment where people working in: it is >> | smalltalk. >> | So, even if i not understand what is inside, i can always select that >> | piece of code and press Cmd-I >> | to inspect it (or explore it) and then i will see everything very >> | clear :) >> >> except when you sitting in a text editor or when you are in a Smalltalk dialect that doesn't have the class you are looking at or the shape of the class in that dialect is different ... > > in addition to my above comment: if your goal to make data dialect > neutral, you making sure it is dialect neutral (no magic ;) , either > by avoiding using non-compatible data structures, or represent them in > a dialect-neutral way. > > Look what we actually doing with JSON: since in smalltalk we can't > have native representation of JS object, we representing it with > surrogate (either dictionary or instance of JSONObject class etc). > > >> >> | >> | As well, as you can do reverse: you can craft a complex thingy, and >> | then send #asObjectLiteral >> | and after some prettyfying, you can make it clearly readable. (not >> | mentioning that you can of course >> | pretty-print it automatically). >> | >> | While with JSON, if you evaluate json code in JS, you will get same >> | JSON as response.. >> | which is cool, because of invariant, but won't make it easier to >> | understand by any bit. >> | >> | > That's fine. >> | > >> | > I also mentioned that YAML is a standard format that is designed to >> | > be very readable by humans while still being parsable by a >> | > machine. You told me that I was missing the point. >> | > >> | yes, because my intent was to use smalltalk syntax (so that we >> | reusing >> | existing codebase, and keep uniformity, which is also important). >> | >> | > That's fine. >> | > >> | > You told me that the point is that you can encode arbitrary objects >> | > in literal arrays and that this representation is optimizable by >> | > the compiler. >> | > >> | >> | right, but that's a side effect (which i discovered discussing here >> | btw). I didn't had that in mind nor putting that as a requirement of >> | design. Still, admit, that this side effect is quite nice :) >> | >> | > That's nice, but it is still not readable by humans (in my opinion) >> | > and I don't want to involve the compiler ... I don't want to >> | > execute code directly from the repository - I want to insert a >> | > parser, so that we have control over the code that gets executed. >> | >> | i know. But my implementation does not evaluating any new code: it >> | just parses the input and transforms it into objects. It doesn't >> | installs new behavior to system. If you don't trust me, you're free >> | to >> | debug the code to see what it does. >> | >> | >> | > >> | > Obviously the goals that you have for this notation do not match up >> | > with the requirements that I have. >> | > >> | >> | my goal is just one: use smalltalk syntax to express data. >> | If you take smalltalker who knows smalltalk and nothing else, i think >> | he will learn to read that notation much faster comparing to learning >> | JSON/STON/YAML first. >> | Because it is already smalltalk and needs just a slight shift in POV >> | to see through braces. >> | That's the main point. >> >> Regarding this goal...you realize that you are entering the territory where you have a solution (using smalltalk syntax to express data) and are looking for a problem to solve. >> >> The problem I had (9 months ago, which was solved by using JSON/STON) is still not solved by your solution... you don't fail in terms of functionality, but in the simple fact that I value the extra syntax that STON/JSON provides that differentiates between arrays and dictionaries ... >> >> You create a literal dictionary/object syntax for Smalltalk and you might have a convert. >> > > In that case, i think , better would be to stay with STON then. > > Dictionaries is quite complex data structure, comparing to lists > (arrays) and basic values (numbers, strings and symbols). How many > other languages, apart from JS, has syntax to denote dictionary-like > structures? Ruby: {:foo => 1, :bar => 2} Clojure: {:foo 1 :bar 2} Python: {'foo': 1, 'bar': 2} frank > I do not see a need in having separate syntax for dictionary. > Because this goes to nowhere in form of never-ending story: > - tomorrow i want syntactic sugar for Sets Because with syntax for lists and dictionaries you can roll any kind of literal you might care for. > - then for Colors A dictionary with keys of 'r', 'g' and 'b', Or 'c', 'm', 'y', 'k'. Or anything else. > - then for Points, Rectangles and Circles A dictionary with 'x' and 'y' keys (or 'rho' and 'theta'), a list of four dictionaries (for the points), and a list with two dictionaries for the points. > ... > - and Pink Elephants > > one of the reasons, why i like smalltalk syntax, is small grammar, > minimal syntactic constructs, > yet high expressive power. > Smalltalk (and LISP) is a good demonstration that massive set of > different syntax sugars/rules and expressive power are not correlating > values. Ah, but it's precisely Lisp's uniformity in appearance that trips people up. And that's precisely why in Clojure a list is (1 2 3), a vector is [1 2 3] and a dictionary is {:a 1 :b 2} - different things are visually distinct. You don't need a _lot_ of difference, because a little goes a long way. frank > If you think otherwise, i think you better start using Perl instead, > where you can find sugars everywhere > and will find that you can write same expression using infinite number of ways, > up to the point that it is no longer possible to understand the code > which you didn't wrote yourself. > >> | >> | > That's fine. >> | > >> | > I am not in dire need of "yet another Notation format". STON >> | > adequately fills the bill for what I need at the moment. >> | > >> | > I have responded to Eliot with more detail about why I consider >> | > JSON to be more readable than your original suggestion. I haven't >> | > commented on the readability of your other suggestions because I >> | > am assuming that you don't have code written to actually parse the >> | > different variations that you proposed. >> | > >> | > Sooo, it's not clear that I can contribute much more. >> | > >> | >> | Dale i value your contribution. You know we can criticize and fight >> | to death. >> | But when i demonstrated that you can use >> | #( Dictionary a -> b) >> | instead of >> | #( Dictionary a b) >> | notation, i actually wanted your input from different perspective: >> | if we going to introduce a smalltalk-based notation (one that using >> | smalltalk syntax), >> | is proposed variant good enough, or there can be alternative(s), >> | which >> | may be better than proposed. >> | As i said, i didn't wanted to contrast it with JSON, and derail the >> | whole thing into fight between camps >> | with zero value for community. >> >> Igor, you are asking form my _opinion_ and I' giving you my _opinion_, and I will repeat it again, I think there needs to be a syntactic difference between dictionary and array ... only to make it possible for the poor human to make sense of things.... the lack of the syntactic demarcation is the weakness here. >> >> I really think that your current variant is way to dependent upon magical ordering...multiple platforms do not represent common classes the same way and positional parameters don't allow for shape changes over time ... way to rigid and structured... > > I think this don't needs additional comment(s) from me, since i > answered to them above. > >> >> Dale >> > > > > -- > Best regards, > Igor Stasenko. >

Oct. 20, 2012

Re: [Pharo-project] building the Mac Cog VM from Jenkins

by StÃ©phane Ducasse

thanks Igor. :) Did you recover from the swimming pool :) Stef On Oct 20, 2012, at 8:30 AM, Igor Stasenko wrote: > On 20 October 2012 08:14, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> This is not a documentation!!! It is a blog. >> > Yes, i will put that in HOWTOBUILD > >> Stef >> > > > > -- > Best regards, > Igor Stasenko. >

Oct. 20, 2012

Re: [Pharo-project] Group metacello question

by StÃ©phane Ducasse

On Oct 19, 2012, at 11:29 PM, Dale Henrichs wrote: > > > ----- Original Message ----- > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > | Sent: Friday, October 19, 2012 1:51:38 PM > | Subject: [Pharo-project] Group metacello question > | > | Hi dale > | > | Q1: > | can I have > | group: 'Pharo' > | > | > | group: 'Pharo2.0.x' > | > | will Pharo2.0.x only gets executed and not Pharo? when I load from > | 2.0? > > Groups are not loaded unless you reference them in a load statement: > > load: #( 'Pharo2.0.x') oops sorry I was too tired. I meant not groups but tags like common, squeak common, pharo1.4.x > > or reference the group name in a `requires:` ... they are intended to be shortcuts or aliases for sets of packages like using the 'Tests' group for collecting all of the test packages. > > You _can_ use groups for naming sets of packages that refer to a platform, but the groups are _not_ automtically loaded ... > > | > | Q2: > | separated question > | and how can I share spec between let say 1.4 and 2.0 > | > | group: 'Pharo1.4.x' > | > | self common: spec > | the rest for 1.4 > | > | group: 'Pharo2.0.x > | self common: spec > | the rest for 2.0 > | > > You should be using the for:do: for conditional stuff: > > spec for: #'pharo1.4.x' do: [ > common specs for 1.4 > ]. > spec for: #'pharo2.0.x' do: [ > common specs for 2.0 > ]. ok then I deduce that for 1.4 and 2.0 this is disjoint but if I have pharo and pharo 2.0.x then there will be loaded in order? an OrderedCollection(#common #squeakCommon #pharo #'pharo2.x' #'pharo2.0.x') > > If you want to know the exact platform atributes available then execute the following in an image: > > (ConfigurationOfYourProject) project attributes > > The attributes that apply: #pharo #pharo1.x, will be listed. > Dale >

Oct. 20, 2012

Re: [Pharo-project] Group metacello question

by StÃ©phane Ducasse

I'm updating the chapter \paragraph{Loading order.} \sd{dale is it correct?} Notice that if you in a system where the platform attributes are (\ct{#common} \ct{#squeakCommon} \ct{#pharo} \ct{#'pharo2.x'} \ct{#'pharo2.0.x'}) (you can obtain this information doing \ct{ConfigurationOf project attributes}) and you have specified three sections such as \ct{#common}, \ct{#pharo} and \ct{#pharo2.0.x}, these sections will loaded one after the other. \begin{code}{} ConfigurationOfCoolBrowser>>baseline09: spec <version: '0.9-baseline'> !\textbf{spec for: \#common do: [}! spec blessing: #baseline. spec repository: 'http://www.example.com/CoolBrowser'. spec package: 'CoolBrowser-Core'; package: 'CoolBrowser-Tests' with: [ spec requires: 'CoolBrowser-Core' ]; package: 'CoolBrowser-Addons' with: [ spec requires: 'CoolBrowser-Core' ]; package: 'CoolBrowser-AddonsTests' with: [ spec requires: #('CoolBrowser-Addons' 'CoolBrowser-Tests' ) ]. spec group: 'default' with: #('CoolBrowser-Core' 'CoolBrowser-Addons' ); group: 'Core' with: #('CoolBrowser-Core' 'CoolBrowser-Platform' ); group: 'Extras' with: #('CoolBrowser-Addon'); group: 'Tests' with: #('CoolBrowser-Tests' 'CoolBrowser-AddonsTests' ); group: 'CompleteWithoutTests' with: #('Core', 'Extras' ); group: 'CompleteWithTests' with: #('CompleteWithoutTests', 'Tests' )]. !\textbf{spec for: \#gemstone do: [}! spec package: 'CoolBrowser-Platform' with: 'CoolBrowser-PlatformGemstone']. !\textbf{spec for: \#pharo do: [}! spec package: 'CoolBrowser-Platform' with: 'CoolBrowser-PlatformPharo']. !\textbf{spec for: \#pharo2.0.x do: [}! spec package: 'CoolBrowser-Addons' with: 'CoolBrowser-Core20']. \end{code}

Oct. 20, 2012

Re: [Pharo-project] building the Mac Cog VM from Jenkins

by Igor Stasenko

On 20 October 2012 08:14, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > This is not a documentation!!! It is a blog. > Yes, i will put that in HOWTOBUILD > Stef > -- Best regards, Igor Stasenko.

Oct. 20, 2012

[Pharo-project] consortium information

by StÃ©phane Ducasse

Hi guys you will hear soon about the consortium - We hope to be ready 10 of november. We have been working on several iteration of the consortium agreement and working with lawyers to make sure that it stays simple and that it will bring a value to you and pharo. In addition we worked on the pharo association (coming really soon). Stef

Oct. 20, 2012

Re: [Pharo-project] building the Mac Cog VM from Jenkins

by StÃ©phane Ducasse

This is not a documentation!!! It is a blog. Stef On Oct 20, 2012, at 1:56 AM, Igor Stasenko wrote: > On 20 October 2012 00:35, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >> On 2012-10-19, at 21:49, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> cmake . >>> make >>> is not longer valid. >>> >>> on mac one should use: >>> cmake . >>> make >>> make install. >>> >>> or just use 'build.sh' >>> script which autogenerated by image (in build directory). >>> >>> i added it, because i also forgetting that last step time to time >>> (since the changes i did lately >>> requires 'make install' step). >> >> so you should update the docs.... >> I didn't know about that one until now... >> > I mentioned it here: > > http://dailyvmotion.wordpress.com/2012/09/18/new-vms-with-nativeboost-callb… > >> the clearly sucks! >> > > > > -- > Best regards, > Igor Stasenko. >

Oct. 20, 2012

Re: [Pharo-project] building the Mac Cog VM from Jenkins

by StÃ©phane Ducasse

Please igor Documentation is important. Once you are done tell me what I should read and try. > > On 2012-10-19, at 21:49, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> cmake . >> make >> is not longer valid. >> >> on mac one should use: >> cmake . >> make >> make install. >> >> or just use 'build.sh' >> script which autogenerated by image (in build directory). >> >> i added it, because i also forgetting that last step time to time >> (since the changes i did lately >> requires 'make install' step). > > so you should update the docs.... > I didn't know about that one until now... > > the clearly sucks! >

Oct. 20, 2012