Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Start a nNew thread

wizard for VerveineJ

by Cyrille Delaunay

see: http://code.google.com/p/moose-technology/issues/detail?id=483&q=verveinej%…

14 years, 6 months

jniport / javaconnect and verveinej

by Tudor Girba

Hi Cyrille, Would you have a bit of time to try to connect to verveinej using jniport or javaconnect? It would be an interesting experience for us, especially that you would have access to the java code now. Cheers, Doru -- www.tudorgirba.com "Being happy is a matter of choice."

14 years, 6 months

Follow-up on Menssana project

by Simon Denier

Hi Here are some news on the Menssana project, which is being built up by Cyrille and me. Remember the goal is to provide high level reports of Smalltalk systems health, using Pharo tools and Moose tools. We have made progress on different points, and we now start to have the full workflow from the source code in Pharo 1.2 to a report browser served by Seaside. Here is how it works: 1) hudson jobs retrieve and update a Pharo 1.2 Core image, also load Moose 2) hudson jobs compute reports on 1.2 and export results as mse files, which are then archived 3) Seaside server offers to browse archived results through a Glamour browser If you want to get a feeling, you can get a working demo with a few steps (and some time) a) Fetch the latest moose+seaside image: http://hudson.moosetechnology.org/job/moose-with-glamour-seaside/lastSucces… b) Run script in a workspace Gofer new squeaksource: 'PharoBenchmarks'; package: 'System-Benchmarking'; load. Gofer new squeaksource: 'Arki'; package: 'Arki-Menssana'; package: 'Arki-MenssanaBrowser'; load c) Start the Seaside server WAKom startOn: 8080. d) Run the script |report| "this part is normally done by Hudson" report := MooseReports createReportFrom: #pharoHealthReport on: MooseReports createModelForPharoKernel. REPConcernBrowserWithActions new browser registerInSeasideOn: report root e) Fire up a browser with the url http://localhost:8080/glamour/pluggable In this demo report results are computed on the fly while you browse the report. So browsing some items may take some times at first as they are lazily computed. -- Simon

14 years, 6 months

Re: could we have a fly by help with the syntax in the query pane?

by Stéphane Ducasse

yes I never know what I can type in there. On Oct 26, 2010, at 2:06 PM, Cyrille Delaunay wrote: > What is a fly by help? a popup window describing how it should be used ? > > 2010/10/26 Stéphane Ducasse <stephane.ducasse(a)inria.fr> > yes under the list of items > > On Oct 26, 2010, at 9:19 AM, Tudor Girba wrote: > > > You mean in the MooseFinder? > > > > Doru > > > > > > On 25 Oct 2010, at 14:49, Stéphane Ducasse wrote: > > > >> cyrille > >> > >> this would good to have a flybyhelp in the query pane. > >> > >> Stef > >> _______________________________________________ > >> Moose-dev mailing list > >> Moose-dev(a)iam.unibe.ch > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > > www.tudorgirba.com > > > > "Not knowing how to do something is not an argument for how it cannot be done." > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

14 years, 6 months

Re: Glamour

by Stéphane Ducasse

no ooooooooooooo Don't limit yourself show us your errors your errors are coool Glamour API should be better :) Stef On Nov 4, 2010, at 12:50 PM, Benjamin wrote: > Ouups :s > > > I'll try to open my both eyes before sending a mail now :) > > > Thank you > > Ben > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

14 years, 6 months

Re: Glamour

by Stéphane Ducasse

On Nov 4, 2010, at 2:43 PM, Hannes Hirzel wrote: > Actually the Glamour API could be considered to be an internal DSL to > describe browsers. I assume that a forth and five iteration are > necessary to make it more user friendly. That is the reason why I did > not pursue Glamour this May. I thought instead of going for Glamour I > can just go through the effort of learning the ToolBuilder builder DSL > -- which in the end is not more difficult either. but glamour is not comparable with toolbuilder. Now do you have all the polymorph widgets described as toolbuilder spec? Because this is the problem. > A note aside: Maybe I push the idea of DSL too much here. The question > is: where do we talk about an API and where does the DSL idea start? > > However --- though there are alot examples -- even more example will > help and I recently enjoyed trying out some of them in the > Moose-Glamour-Image. > > --Hannes > > On 11/4/10, Stéphane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> no ooooooooooooo >> >> Don't limit yourself show us your errors >> >> >> your errors are coool >> >> Glamour API should be better :) >> >> Stef >> >> On Nov 4, 2010, at 12:50 PM, Benjamin wrote: >> >>> Ouups :s >>> >>> >>> I'll try to open my both eyes before sending a mail now :) >>> >>> >>> Thank you >>> >>> Ben >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

14 years, 6 months

Re: Glamour

by Stéphane Ducasse

I like your spirit :) and this is great to see your questions. Stef On Nov 3, 2010, at 1:04 PM, Benjamin wrote: > hello, there still are things I do not understand in your examples, and I hope you could help me because I really want to understand how Glamour works ^^ > > When you write : > > t1 transmit to: #three; > from: #one -> #selectionPath; > > what happen ? > > Because I have looked for implementors of selectionPath, put a self halt in each of them, run your browser, but no halt has been thrown, so I'm confused (again). > > Moreover, I now know how to show a list, and how to pass the selected items from the list to another column/row, but I wonder how to use the selected item as a parameter for a method and how to get the answer of this method back to be used in another part. > > > I keep hope to understand how it works ^^ > > > > Benjamin > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

14 years, 6 months

Re: PackageOrganizerCache

by Stéphane Ducasse

On Oct 27, 2010, at 4:48 PM, Simon Denier wrote: > > On 27 oct. 2010, at 16:27, Cyrille Delaunay wrote: > >> Hello, >> >> I'm currently looking at the use of the PackageOrganizerCache in Moose. >> There was some work in pharo about a new, more performant, better-structured (I think it's the idea ? :)) 'Package system' called RPackage. >> So before doing anything, I would like to know more about the use of PackageOrganizerCache: >> - Why do we use a cache ? I guess this is because accessing directly parent packages of specific classes or methods was to slow using the current package system. >> - If this is the good answer :), why was it too long? could another package system (RPackage) solve this problem and avoid us to use a cache ? >> - For which kind of task is used the packageCache in Moose? I saw that it was used at the import of smalltalk code, to link classes and method to their parent package, is that all ? > > Basically, yes, yes, and yes. > > The current package system (PackageOrganizer + PackageInfo) is reeeally slow for some tasks, like computing package of methods (to detect class extensions), and it really brought down the Smalltalk importer to its knee on even not so large models. The big problem now is linking the package organizer to system events, so that it updates itself whenever a package is added, renamed, removed, changed... So far this is not done in RPackage because the event were not there. But now they are available so we should check that. I will check and discuss that with cyrille because this will help us. > This was not done with PackageOrganizerCache because it's a bit difficult and because it was just a workaround at the time. Now RPackage should replace the current organizer and has to take care of such events. It also appear that RPackage initializes itself faster than PackageOrganizerCache (probably because it's more clever in its usage of PackageInfo API). I do not know. So long that I looked at Rpackage. > Anyway, it's a problem specific to the Smalltalk importer, not to Moose or Famix in general. > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

14 years, 6 months

Re: [Pharo-project] Proposal: adding 261 named colors

by Alexandre Bergel

Hi! The last version of Mondrian contains the class XKCDColor produced by Johan Fabry. You can try (also accessible from the example menu in a MOEasel/examples/colors: | cols | cols := (XKCDColor colormap keys collect: [:cnam | XKCDColor named: cnam]) sortedAs: #hue. view shape rectangle withoutBorder. view nodes: cols forEach: [:col | view shape rectangle fillColor: col; width: 65; height: 25. view node: col. view shape label text: col name. view node: col. view verticalLineLayout]. view gridLayout gapSize: 0 Cheers, Alexandre On 3 Nov 2010, at 11:07, Johan Fabry wrote: > Hi Doru, Alex, > > I dont know how this is advancing for Pharo, apparently it is not considered a priority (which I understand of course). So in the mean time you could consider adding it to Mondrian/Moose, as Doru said. The .st file is in attachment, a Mondrian script to produce a reasonably sorted overview of the colors is below. Maybe you will want to do some cleaning/censoring of color names. I personally think that there is no harm here but I have been known to be liberal sometimes :-) > > |cols| > cols := SortedCollection new sortBlock: [:c1 :c2 | (c1 hue) > (c2 hue) ]. > cols addAll: (XKCDColor colormap keys collect: [:cnam | XKCDColor named: cnam]). > view shape rectangle withoutBorder. > view nodes: cols > forEach: [:col | view shape rectangle fillColor: col; width: 65; height: 25. view node: col. view shape: (MORectangleShape new text: col name; withoutBorder). view node: col. view verticalLineLayout]. > view gridLayout gapSize: 0 > > <XKCDColor.st> > > On 24 Oct 2010, at 04:12, Tudor Girba wrote: > >> Hi Johan, >> >> I would definitely be interested in getting this as an external library around Mondrian and Moose. >> >> Cheers, >> Doru > > -- > Johan Fabry > jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 6 months

Larger fonts in DistributionMaps

by Mariano Martinez Peck

Hi. I need to have larger fonts for the legends of a DistributionMap. For example, in the attached screenshot I would like to use bigger fonts for the properties and for the packages names. Is that possible? I surf a little the code but I didn't find anything. Thanks in advance, Mariano

14 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev