Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

FAME being built for an hour already
by Yuriy Tymchuk 12 Jun '13

12 Jun '13

So fame job is already taking 1hour when it usually took 48sec. It looks like stuck at Creating starter scripts pharo and pharo-ui + ./pharo Pharo.image save fame I haven't figured out the problem yet. Does anybody have some suggestion that can help? Uko -- View this message in context: http://moose-dev.97923.n3.nabble.com/FAME-being-built-for-an-hour-already-t… Sent from the moose-dev mailing list archive at Nabble.com.

4 6

Re: [Pharo-dev] Modification on CollectionsExtensions
by Guillaume Larcheveque 12 Jun '13

12 Jun '13

I think the simplest solution is to keep both and that flatCollect directly call gather: If you agree with that, I will correct the moose extension package 2013/6/11 Stéphane Ducasse <stephane.ducasse(a)inria.fr> > gather: sucks as a name. > flatCollect: is much better so do not remove it. > > On Jun 11, 2013, at 4:53 PM, Sebastian Tleye <stleye(a)gmail.com> wrote: > > If they are not different so a better way would be replace #flatenCollect: > by #gather: > but anyway, moose people should decide and commit the change since i am > not a moose developer. > > > 2013/6/11 Marcus Denker <marcus.denker(a)inria.fr> > >> >> On Jun 11, 2013, at 4:24 PM, Frank Shearar <frank.shearar(a)gmail.com> >> wrote: >> >> > On 11 June 2013 14:18, Sebastian Tleye <stleye(a)gmail.com> wrote: >> >> Hello, >> >> >> >> Fixing some bugs in Traits we realized that it would be good idea to >> use >> >> CollectionsExtensions package (it has some useful functions), also it >> would >> >> be great to include CollectionsExtensions in Pharo 3.0. >> > >> > Is this the HPI library? I seem to recall TraitClasses [1] using it. >> >> CollectionExtension is from Moose. >> >> the Trait based Stream refactoring was done some years ago but has not >> been used >> or maintained. >> >> Marcus >> > > > -- *Guillaume Larcheveque*

3 3

Re: #stable not defined
by Stephan Eggermont 12 Jun '13

12 Jun '13

Sean wrote >Thomas Worthington-2 wrote >>Regardless, what should I do to get SOME version of, say, Moose >>or CairoGraphics loaded up? >I tried to load Moose per the instructions on their website [1] and got and error, so I'm not sure. I forwarded the error to >their mailing list [2] Could it be a well known vm bug? https://pharo.fogbugz.com/default.asp?10395 The released version of Moose is 4.7, which is based on Pharo 1.4 Moose 4.8 is based on Pharo 2.0 and is very close to release, and perfectly useable. Installing Moose from Monticello packages takes a lot of time as it is large, so I recommend downloading a development build from http://www.moosetechnology.org/download/4.8 I fully agree that suggesting to install #stable versions of configurations where stable is not defined is not very useful. Stephan

1 0

Re: [Pharo-dev] Modification on CollectionsExtensions
by Sebastian Tleye 11 Jun '13

11 Jun '13

I don't know, i should see the implementation, i just want to remove the dependency between CollectionsExtensions and Nile and one way to do it is modifying #flatCollect: implementation. if they are the same #flatCollect: could be remove safely replaced. 2013/6/11 Camille Teruel <camille.teruel(a)gmail.com> > > On 11 juin 2013, at 15:18, Sebastian Tleye wrote: > > > Hello, > > > > Fixing some bugs in Traits we realized that it would be good idea to use > CollectionsExtensions package (it has some useful functions), also it would > be great to include CollectionsExtensions in Pharo 3.0. > > > > One "problem" we found is that CollectionsExtensions is depending on a > Nile Package (that's not a desired feature). > > In the method Collection>>flatCollect: there is a line refering to a > nile function "nsWriteStream". > > How this #flatCollect: is different from #gather: anyway? > > > > > If i change "nsWriteStream" for "writeStream" the dependency disapears. > > > > I also run all the tests and they are working, so i was wondering if it > would be possible to commit the change. > > > > Thanks. > > >

2 1

ConfigurationOfMoose Error in Pharo 2.0
by Sean P. DeNigris 11 Jun '13

11 Jun '13

In answering a question on the Pharo users list [1], I tried to load Moose based on the instructions at [2]: Gofer new smalltalkhubUser: 'Moose' project: 'Moose'; package: 'ConfigurationOfMoose'; load. (Smalltalk at: #ConfigurationOfMoose) perform: #loadDevelopment And got: SmallInteger(Object)>>doesNotUnderstand: #isEmpty MetacelloMCVersionSpec>>resolveToLoadableSpecs:map: where the SmallInteger in question was 602151175 [1] http://forum.world.st/stable-not-defined-td4692873.html [2] http://www.moosetechnology.org/download/pharo ----- Cheers, Sean -- View this message in context: http://forum.world.st/ConfigurationOfMoose-Error-in-Pharo-2-0-tp4692881.html Sent from the Moose mailing list archive at Nabble.com.

1 0

Roassal, SVG export, padding
by mathieubmddehouck＠mailoo.org 11 Jun '13

11 Jun '13

Hi I'm sorry to come with my problems, but I'm writing my internship report and I need some picture so I went back to Roassal. - Why when exporting in SVG it does not export the whole canvas but only a small part ? I had problem with my Ubuntu so I upgrade to 13.04 and noticed some nice stuffs. - Athens does not work, there is a problem with font rendering with Cairo and Ubuntu 13.04. ( I have reproduced the problem with Damien and Erwan computer ) Igor had a look, but he didn't find the problem. Then I took a new image and load my code in it. - When the mouse go over a node I have a ROPermissiveParent >> padding: failure (assertion failed), it seems that the padding is nil, I thought it has been solved for a while. Regards Mathieu

2 3

Modification on CollectionsExtensions
by Sebastian Tleye 11 Jun '13

11 Jun '13

Hello, Fixing some bugs in Traits we realized that it would be good idea to use CollectionsExtensions package (it has some useful functions), also it would be great to include CollectionsExtensions in Pharo 3.0. One "problem" we found is that CollectionsExtensions is depending on a Nile Package (that's not a desired feature). In the method Collection>>flatCollect: there is a line refering to a nile function "nsWriteStream". If i change "nsWriteStream" for "writeStream" the dependency disapears. I also run all the tests and they are working, so i was wondering if it would be possible to commit the change. Thanks.

1 0

Issue 910 in moose-technology: [VerveineJ] Some methods have 'private' modifier in source code but not in model
by moose-technology＠googlecode.com 10 Jun '13

10 Jun '13

Status: New Owner: anquetil...(a)gmail.com CC: damien.c...(a)gmail.com Labels: Type-Defect Priority-High Component-VerveineJ New issue 910 by damien.c...(a)gmail.com: [VerveineJ] Some methods have 'private' modifier in source code but not in model http://code.google.com/p/moose-technology/issues/detail?id=910 1- Take ant-1.8.2.mse 2- Search methods with each isProtected not and: [each isPublic not and: [each isPrivate not and: [each isStub not]]] 3- Some methods are private here

1 2

CI slaves not doing well
by Yuriy Tymchuk 10 Jun '13

10 Jun '13

Hi everyone. As far as I know cloud stack should be online. But when I check the status of the slave it says "starting". Does anybody know what can be done to help it get started at last :) Cheers. Uko -- View this message in context: http://moose-dev.97923.n3.nabble.com/CI-slaves-not-doing-well-tp4027831.html Sent from the moose-dev mailing list archive at Nabble.com.

2 2

Re: PetitJava
by Yuriy Tymchuk 10 Jun '13

10 Jun '13

Hi, so there are a few parts. 1) Visitors I suggest that abstract visitor should guide you how to visit this node. For example just do 'visitNodes: aPrimaryWithSelectorsNode codeList' so when someone will overwrite it he will know that he should pay attention to codeList data. Also comment will be lovely to have and this is a tough part as almost no classes in PJ have comments. 2). AST nodes The reason why we create an AST is that PetitParser's native parse result are arrays, and we want more structured data. For instance this.getCommand().getContext().getUser().getActiveProfile() is a method call. It has a selector "getActiveProfile" it has no parameters and it's invoked on this.getCommand().getContext().getUser(). I may be wrong about this, but on the other hand current AST is constructed like this. So maybe if you need some other kind of AST you should create it and make one more subclass of parser that will construct that. Also I'll sent a copy to moose-dev because maybe people there will have better vision. Cheers Uko On 29 трав. 2013, at 19:33, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > Hi, > > I'm not sure what exactly you want out of the visitor pattern. It seems like the current accept.. methods (that aren't either 'TO DO' or #subclassResponsibility, that is) just ask you to #visitNode: or #visitNodes: for the various instance variables in the AST classes. Am I missing something here? I must say that I haven't used the visitor pattern with parsed results before, and am not sure what you want and/or need out of this. > > As for PrimaryWithSelectorsNode, after looking back at it, I can see that I have obscured what the 'primary' was from when it was parsed out. however, in looking at what could constitute a primary (versus the selectors part), I find myself confused with what answering a primary would be. I could by most anything - for a single item (boolean, literal, variable) to something very complex (such as a string of identifiers hanging off of an identifier with or without message sends on the end). Instead I attempted to simplify it into an array of the parts so that I could iterate over them as needed. sometimes I would like to find the first in the list, sometimes the last, and sometimes I'd like to search the whole list for a specific call (if present) in the middle. > > so, take the code: > this.getCommand().getContext().getUser().getActiveProfile() > The current PJPrimaryWithSelectorsNode will have these in the codeList array: > this > getCommand() > getContext() > getUser() > getActiveProfile() > I did change the behaviour of the parsed #primaryWithselectors - previously it would have bundled this and getCommand() together into one unit identified as 'primary' and all of the other methods as an array of 'selectors'. > > similarly, this code: > new SearchUrl(Search.class).set(parm1, p1).set(parm2, params.get2(p2)).set(parm3, p3).getHref() > will return the codeList array: > new SearchUrl(Search.class) > set(parm1, p1) > set(parm2, params.get2(p2)) > set(parm3, p3).getHref() > Previously, it would identify the first item of the array as the primary, and the rest as the selectors. Which does make a lot of sense to me. > > finally, this code: > this.context.getUser().getActiveProfile().getProfileProperties() > will return in the code array: > this > context > getUser() > getActiveProfile() > getProfileProperties() > Previously, primary would have consisted of the array > this > context > getUser() > while selectors would have been the array of > getActiveProfile() > getProfileProperties() > > I should note that I'm not a Java coder myself and am not clear on how Java coders identify the parts of their code. I have tried to mostly follow what was previously there in the parser as it was clearer than what I'd likely come up with. However, I can't really see myself why the 'primary' was primary in the previous examples - is it clear and I should revert back, and have the visitor visit the restored primary and selectors? or should I have the visitor visit each part of the stacked structure that the Java coder has presented us? Which way would you prefer it - I'll modify it to fit your desires. > > Thanks, > Chris > > On Tue, May 28, 2013 at 10:55 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > HI, > > I've checked the changes. `acceptPrimaryWithSelectorsNode:` has only a flag so I didn't get how should I accept it and started to check out what the idea is. I still don't get it. It has some code list that is usually an array. Why do we need that node? What code entity does it represent? It looks like instead of building an AST from parsed arrays we are wrapping them in other classes. > > Yuriy > > On 28 трав. 2013, at 21:30, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > >> Hi. >> >> I've added the missing method (as well as related missing #acceptVisitor: methods on most of the other nodes that I've added) in the latest change. >> >> If you have any other questions or requests, please let me know. >> >> Thanks, >> Chris Cunningham >> >> >> On Tue, May 28, 2013 at 7:45 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> Thank you >> >> Надіслано з iPhone >> >> 28 трав. 2013 о 17:18 Chris <cunningham.cb(a)gmail.com> написав(ла): >> >> > Thanks for letting me know. I'll fix that today. >> > >> > Sent from my iPhone >> > >> > On May 28, 2013, at 1:59 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> > >> >> Hi, >> >> >> >> your changes to PetitJava break my builds on fast. The problem is that `acceptVisitor:` of PJPrimaryWithSelectorsNode is not implementing `acceptVisitor: aVisitor` method, and so PJASTNodeVisitor is not implementing some visiting method that can give a hint on what should I do in my visitor subclass. >> >> >> >> Thank you for your contributions. >> >> Uko >> > >

4 10

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev