tracker issues to the mailing list
by Tudor Girba
Hi,
I noticed that most problems are posted twice (once once on the mailing list, and once in the tracker), so I added this mailing list for the notifications of the issue tracker. Like this we can add the issues to the tracker and keep the mailing list messages for clarifying issues.
I also noticed that the Pharo mailing list took the same route, so I thought of trying. If you have other preferences, just let me know.
Cheers,
Doru
--
www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
12 years, 10 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."
12 years, 10 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/lastSucc...
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
12 years, 10 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
12 years, 10 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
12 years, 10 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
12 years, 10 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
12 years, 10 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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
12 years, 11 months
