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

Re: [Pharo-dev] Compilation error of the PharoEnterprise book with luatex

by stepharo

The problem is not related to that. To display the full encoding the guys here (damien * damien) only found luaTex working. But LuaTex does not work well on our machines apparently. Le 29/11/14 02:38, Ben Coman a Ã©crit : > kilon alios wrote: >> have you tried MacTex ? >> >> https://tug.org/mactex/ >> >> its what I use with my iMac and so far has been working for me >> without any issues. > > I also ended up using MaxTex fairly easily. (I can't remember which > other one originally tried that had some issues.) > cheers -ben > >> >> On Sat, Nov 29, 2014 at 12:02 AM, Luc Fabresse >> <luc.fabresse(a)gmail.com <mailto:luc.fabresse@gmail.com>> wrote: >> >> Hi All, >> >> I cannot compile the latest version in >> SquareBracketAssociates/EnterprisePharo.git >> My problem is that the "FiraSans" cannot be found. >> But in common.tex, the font path is correctly set up and the font is >> there. >> >> So on CI which version of luatex is used? >> I did not find it in the Jenkins log. >> >> I am using LuaTeX, Version beta-0.79.1 (TeX Live 2014/MacPorts >> 2014_1) (rev 4971) >> >> Cheers, >> >> #Luc >> >> > > >

Nov. 29, 2014

Re: [Pharo-dev] Compilation error of the PharoEnterprise book with luatex

by stepharo

Same on my machine :( So I have a script that copy the chapter in another folder. TeX sucks! Stef Le 28/11/14 23:02, Luc Fabresse a Ã©crit : > Hi All, > > I cannot compile the latest version in > SquareBracketAssociates/EnterprisePharo.git > My problem is that the "FiraSans" cannot be found. > But in common.tex, the font path is correctly set up and the font is > there. > > So on CI which version of luatex is used? > I did not find it in the Jenkins log. > > I am using LuaTeX, Version beta-0.79.1 (TeX Live 2014/MacPorts 2014_1) > (rev 4971) > > Cheers, > > #Luc

Nov. 29, 2014

Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree

by stepharo

thanks I added it to pharo weekly http://pharoweekly.wordpress.com/2014/11/29/github-for-pharo-using-sourcetr… Le 27/11/14 21:46, kilon alios a Ã©crit : > Hello pharoers , at last , my video tutorial for those that are not > familiar with git and github, has been uploaded to YouTube. I describe > the very basics of the process and give you enough information to > create a github repository, clone the online repository to your hard > driver and use the hard drive copy to commit changes to your code, > upload and download your commits to and from your github repo . I use > sourcetree to make the interaction with git as gui based as you are > used with Pharo. > > The tutorial can be watched here > > https://www.youtube.com/watch?v=n2WNYDtO0cE > > and these are the relevant links for whatever is used in the tutorial > > Git > http://git-scm.com > > GitHub > https://github.com/ > > Sourcetree > http://www.sourcetreeapp.com > > SmartGit > http://www.syntevo.com/smartgit > > if you have any issue , problem and compliant, dont be shy, share it :)

Nov. 29, 2014

Glamour-core maybe missing from Pharo40/main

by Ben Coman

Sometimes when I am hacking around the system, I use Monticello to review just what I've changed. In build 40390, I did a <Changes> of Glamour-Core (BernardoContreras.286) against Pharo40/main and got _lots_ of changes. Then it seems that this package is not in Pharo40/main. Should it be? Maybe this is because its an external package - but then its repository is not listed? cheers -ben

Nov. 29, 2014

Re: [Pharo-dev] [squeak-dev] IdentitySet>>collect:

by Ben Coman

Levente Uzonyi wrote: > The problem with changing #species is that it's overused. There are at > least three different things it's used for in the Collection hierarchy: > - the class of the object returned by #collect: (Set's subclasses are > the exception since 2000 or so, except for WeakSet, but that's really > strange, and should revisited) > - the class of the object returned by #select: and friends > - the class used for comparison of collections So should there be #collectSpecies ? Which defaults to "^self species" and is overidden as required. In the case of Sets, you start with an "unordered collection without duplicates", but since #collect can introduce duplicates, you end up with "an unordered collection with duplicates" --> Bag (per Dave's suggestion) So I think its reasonable that the following two snippets should produce the same result. oc := OrderedCollection newFrom: #( 1 2 3 4 5 ). (oc collect: [ :e | e even ]) occurrencesOf: true. "--> 2" s := Set newFrom: #( 1 2 3 4 5 ). (s collect: [ :e | e even ]) occurrencesOf: true. "--> 2" which you get with the following change... Set>>collectSpecies ^Bag Set>>collect: aBlock | result | result := self collectSpecies new: self size. array do: [:each | each ifNotNil: [result add: (aBlock value: each enclosedSetElement)]]. ^ result > > HashedCollection >> #select: uses #species. Changing IdentitySet >>> #species to return a Set would break #select:, because a ~~ b doesn't > imply a ~= b. IdentitySet is the optimal class for the return value of > IdentitySet >> #select:, because it's guaranteed to be able to hold all > selected values. I think the same applies to all other kind of sets (and > collections, because #select: is simply reducing the number of elements). > > This is not the first time this discussion comes up. There was one in > 2003[1], but the thread is hard to follow. And there was one in 2009[2]. > I think the conclusion was that it's better to leave the method as it > is, because there's no better way to do it. > Sure, we could use #species in #collect:, but it would break quite a lot > of stuff. For example: > > | k | > k := KeyedSet keyBlock: [ :each | each first ]. > k add: #[1]; add: #[2]. > k collect: [ :each | each size ] That works with the above change to produce --> a Bag(1 1) > > Currently this snippet returns "a Set(1)". Using #species in #collect: > (via #copyEmpty) one would get an error, because SmallInteger does not > understand #first. Changing the #species of KeyedSet would break #select:. > > So IMHO when you #collect: from a set, you should always use > #collect:as:. Here is a (partial) list of methods which send #collect: > to a Set: > > Categorizer >> #changeFromCategorySpecs: > ClassFactoryForTestCase >> #createdClassNames > Dictionary >> #unreferencedKeys > MCDependencySorterTest >> > #assertItems:orderAs:withRequired:toLoad:extraProvisions: > MessageNode >> #analyseTempsWithin:rootNode:assignmentPools: > MethodNode >> #referencedValuesWithinBlockExtent: > SetTest >> #testCollect > SetWithNilTest >> #runSetWithNilTestOf: > > There are probably many more, but we should fix all of them. A static > analyzer could help a lot. > > Levente > > [1] > http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-February/052659… > > [2] > http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-November/141016… > > > > > On Wed, 26 Nov 2014, David T. Lewis wrote: > >> It seems to me that Object>>species is intended to handle this sort of >> issue. >> >> For IdentitySet, it answers what Eliot was expecting: >> >> IdentitySet new species ==> IdentitySet >> Set new species ==> Set >> >> However, IdentitySet>>collect: does not make use of this, and it answers >> a Set for the reasons that Levente explained. >> >> Answering an Array or and OrderedCollection would not really make sense, >> because sets are unordered collections (but Bag might be better). Bag is better. >> >> Shouldn't we have an implementation of IdentitySet>>species that answers >> Set (or Bag), with a method comment explaining why this is the case, and >> with all of the collection methods using #species to answer the right >> kind of result? >> >> I note that IdentitySet>>collect: answers a Set, but IdentitySet>select: >> sends #species and therefore answers an IdentitySet. >> >> So I think that if we want the #species of an IdentitySet to be a Set, >> then we should make it so, and give it a method comment to explain the >> rationale. And the #collect: and #select: methods should both answer a >> result of that #species. I think the species of #collect: and #select: are intrinsically different. #collect: is a transformation. >> >> Dave >> >> >> On Thu, Nov 27, 2014 at 01:14:30AM +0100, Levente Uzonyi wrote: >>> Your example hides the problem of ordering - what Tobias is asking >>> about - >>> so here's another: >>> >>> (IdentitySet withAll: #(1 1.0)) collect: [ :each | each class ] >>> >>> If IdentitySet >> #collect: were returning an Array, then what would >>> be the >>> answer? >>> >>> { SmallInteger. Float } or { Float. SmallInteger } ? --> a Bag(SmallInteger Float) >>> >>> If you really want to have the resulting collection have the same size, >>> but avoid the problem with ordering, then what you really need is a Bag. To me that makes the most sense. >>> >>> On Thu, 27 Nov 2014, Frank Lesser wrote: >>> >>>> Hi Tobias, >>>> agree, a problem of "OrderedCollection" >>>> not to break a lot of other things we could return an Array. >>>> but for me collecting has priority. >>>> Frank >>>> >>>> -----Urspr?ngliche Nachricht----- >>>> Von: squeak-dev-bounces(a)lists.squeakfoundation.org >>>> [mailto:squeak-dev-bounces@lists.squeakfoundation.org] Im Auftrag von >>>> Tobias >>>> Pape >>>> Gesendet: Donnerstag, 27. November 2014 00:48 >>>> An: The general-purpose Squeak developers list >>>> Betreff: Re: [squeak-dev] IdentitySet>>collect: >>>> >>>> >>>> On 27.11.2014, at 00:34, Frank Lesser >>>> <frank-lesser(a)lesser-software.com> >>>> wrote: >>>> >>>>> hmm, not convinced >>>>> >>>>> (IdentitySet withAll: #(1 1.0)) collect: [:e| e asInteger ] >>>>> OrderedCollection(1 1 ) >>>>> >>>>> in LSWVST ( one-to-one ), you collect results of evaluating a block on >>>>> objects. >>>>> >>>>> Frank >>>>> maybe I am wrong ... >>>> >>>> Where would the order come from for that _Ordered_Collection? An unordered OrderedCollection --> Bag cheers -ben

Nov. 29, 2014

Re: [Pharo-dev] Compilation error of the PharoEnterprise book with luatex

by Ben Coman

kilon alios wrote: > have you tried MacTex ? > > https://tug.org/mactex/ > > its what I use with my iMac and so far has been working for me without > any issues. I also ended up using MaxTex fairly easily. (I can't remember which other one originally tried that had some issues.) cheers -ben > > On Sat, Nov 29, 2014 at 12:02 AM, Luc Fabresse <luc.fabresse(a)gmail.com > <mailto:luc.fabresse@gmail.com>> wrote: > > Hi All, > > I cannot compile the latest version in > SquareBracketAssociates/EnterprisePharo.git > My problem is that the "FiraSans" cannot be found. > But in common.tex, the font path is correctly set up and the font is > there. > > So on CI which version of luatex is used? > I did not find it in the Jenkins log. > > I am using LuaTeX, Version beta-0.79.1 (TeX Live 2014/MacPorts > 2014_1) (rev 4971) > > Cheers, > > #Luc > >

Nov. 29, 2014

Re: [Pharo-dev] [squeak-dev] Re: IdentitySet>>collect:

by Eliot Miranda

Hi Nicolai, On Nov 28, 2014, at 4:01 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014-11-28 16:39 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: >> >> >> On Fri, Nov 28, 2014 at 4:26 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> > On 28 Nov 2014, at 15:35, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> > >>> > >>> >> On 27 Nov 2014, at 08:21, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >> >>> >> >>> >>> On 26 Nov 2014, at 19:19, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> >>> >>> >>> Hi All, >>> >>> >>> >>> IdentitySet>>collect: answers a Set, not an IdentitySet. Anyone else agree this is a serious bug? Anyone else disagree? >>> >>> >>> >>> WTF?? >>> >>> >>> >>> (IdentitySet withAll: #(1 2 3 1.0 2.0 3.0)) collect: [:e| e] a Set(1.0 2 3) >>> >> >>> >> Yes, I would say so. I think we fixed some others like that already (not 100% sure) >>> >> >>> >> I added an issue tracker entry >>> >> >>> >> 14535 IdentitySet>>collect: answers a Set, not an IdentitySet. >>> >> https://pharo.fogbugz.com/f/cases/14535 >>> >> >>> > >>> > #collect: directly uses Set in Set>>#collect, I committed a fix (to the issue tracker, to be reviewed) >>> > to use âself speciesâ instead (plus the example from above as a test in IdentitySetTest). >>> > >>> > Marcus >>> >>> I think that is the most logical thing to do, it is what I would expect. >>> >>> I know others have cases where that is not really what you want (some of Set's subclasses are pretty special), but it is still a good default, while #collect:as: can be used for all other cases (and subclasses can override #species again if they want). >> >> Hmm... errors found by the test runner on that change. >> >> https://ci.inria.fr/pharo/job/Pharo-4.0-Issue-Validator/17683//artifact/val… >> >> So we will need to check... >> >> Marcus > > > In pharo, the problem is the OCKeyedSet, but the same happens in squeak with a KeyedSet. > Changing Set>>#collect: to use "self species new" the following code fails: > > k:=KeyedSet new keyBlock:[:e | e name]. > k addAll:{ Color red . Color blue . Color green}. > k collect:[:e | e ]. > --> MessageNotUnderstood: Color>>key And if you implement species in KeyedSet to answer Set (which should fix this one issue) does anything else break? Eliot (phone)

Nov. 29, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by volkert＠nivoba.de

Am 27.11.2014 um 11:46 schrieb Sven Van Caekenberghe: >> On 27 Nov 2014, at 11:14, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: >> >> SmalltalkHub is slow, so donât click too fast :-( >> >> While Iâm grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We donât have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long... >> >> Itâs better to use some mainstream platform such as github. >> Weâll we have support for it in Pharo 4? >> >> It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo. > I think it is important to have a serious online system written in Pharo and in daily use (you know, eat your own dog food). > > There is also a difference between the system itself and the way it is deployed/managed. > > Please do not underestimate how much work this is for something that is used so heavily, like StHub. > Yes, this is important for Pharo in some way. But such a the system have to be maintained and developed further/keept up to date, otherwise it has a bad impact. But i have the feeling in Pharo so many cool things started and then slowly waste away ... Why? The Community is to small, ... the cool guys move further. The PhD is finished ... Gaps hard to close. Would be sad, if this happens to SmalltalkHub. There should be only 2-3 public, open source key systems (or type of systems) where to put the focus on and give them a long term perspective & support from the association / consortium or other donators. And the systems and its building blocks should move with Pharo in the future. And the system should be in some obviously way special & exceptional ... and part of the "Pharo Masterplan". (a) Data Analysis & Visualization System => ?? MOOSE ?? => Key Building Blocks: f.e. Roassal2/3D, ZincHTTP, NeoCSV, NeoJSON, ... (b) Online/Web System => ?? SmalltalkHub ?? => Key Building Blocks: f.e. Amber, Seaside, ZincHTTP, NeoCSV, NeoJSON, ... (c) A Cool Game (would love it) => ??? => Key Building Blocks: ??? (d) ??? I know, it is easy to say. But the best promotion for Pharo are cool systems in Pharo. But maybe Pharo has not more potential than doing one type of systems right and ongoing, f.e. (a). I have no problems with it. I like Pharo for (a) as i like Erlang/OTP for (b) and Lua/Love2D for (c). The coolest would be a perspective for (a), (b), (c) and (d) in Pharo. But i do not see it ... But yes, it is better to do one or two things good, and not a five bad. My 2 cents, Volkert

Nov. 29, 2014

Re: [Pharo-dev] [squeak-dev] Re: IdentitySet>>collect:

by Nicolai Hess

2014-11-28 16:39 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On Fri, Nov 28, 2014 at 4:26 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> >> > On 28 Nov 2014, at 15:35, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> > >> > >> >> On 27 Nov 2014, at 08:21, Marcus Denker <marcus.denker(a)inria.fr> >> wrote: >> >> >> >> >> >>> On 26 Nov 2014, at 19:19, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >> >>> >> >>> Hi All, >> >>> >> >>> IdentitySet>>collect: answers a Set, not an IdentitySet. Anyone >> else agree this is a serious bug? Anyone else disagree? >> >>> >> >>> WTF?? >> >>> >> >>> (IdentitySet withAll: #(1 2 3 1.0 2.0 3.0)) collect: [:e| e] a >> Set(1.0 2 3) >> >> >> >> Yes, I would say so. I think we fixed some others like that already >> (not 100% sure) >> >> >> >> I added an issue tracker entry >> >> >> >> 14535 IdentitySet>>collect: answers a Set, not an IdentitySet. >> >> https://pharo.fogbugz.com/f/cases/14535 >> >> >> > >> > #collect: directly uses Set in Set>>#collect, I committed a fix (to the >> issue tracker, to be reviewed) >> > to use âself speciesâ instead (plus the example from above as a test in >> IdentitySetTest). >> > >> > Marcus >> >> I think that is the most logical thing to do, it is what I would expect. >> >> I know others have cases where that is not really what you want (some of >> Set's subclasses are pretty special), but it is still a good default, while >> #collect:as: can be used for all other cases (and subclasses can override >> #species again if they want). >> >> > Hmm... errors found by the test runner on that change. > > > https://ci.inria.fr/pharo/job/Pharo-4.0-Issue-Validator/17683//artifact/val… > > So we will need to check... > > Marcus > In pharo, the problem is the OCKeyedSet, but the same happens in squeak with a KeyedSet. Changing Set>>#collect: to use "self species new" the following code fails: k:=KeyedSet new keyBlock:[:e | e name]. k addAll:{ Color red . Color blue . Color green}. k collect:[:e | e ]. --> MessageNotUnderstood: Color>>key

Nov. 29, 2014

Re: [Pharo-dev] Compilation error of the PharoEnterprise book with luatex

by kilon alios

have you tried MacTex ? https://tug.org/mactex/ its what I use with my iMac and so far has been working for me without any issues. On Sat, Nov 29, 2014 at 12:02 AM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > Hi All, > > I cannot compile the latest version in SquareBracketAssociates/ > EnterprisePharo.git > My problem is that the "FiraSans" cannot be found. > But in common.tex, the font path is correctly set up and the font is there. > > So on CI which version of luatex is used? > I did not find it in the Jenkins log. > > I am using LuaTeX, Version beta-0.79.1 (TeX Live 2014/MacPorts 2014_1) > (rev 4971) > > Cheers, > > #Luc >

Nov. 28, 2014