Shoot!
Thanks for spotting it! I'm currntly on holidays but i'll check this out asap.
--- Mensaje Original ---
Desde: "Alexandre Bergel" <alexandre.bergel(a)me.com>
Enviado: 17 de septiembre de 2013 5:18 PM
Para: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Asunto: [Moose-dev] Re: GraphET x-axis label - bug?
Thanks for having spotted the bug.
In the meantime, you may want to check this how to add labels in a "manual" way:
http://stackoverflow.com/questions/18831437/graph-et-x-axis-labels/18853456…
Cheers,
Alexandre
On Sep 16, 2013, at 11:18 AM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
> Hello,
>
> I am starting to use GraphET and looks really nice. While learning to script with it, I stumbled upon this script that does not place x-axis label in the correct place. In fact the x-axis label is superimposed on y-axis one. Here's how you can reproduce it:
>
> tmpBrowser := GLMDashboard new.
> tmpBrowser addPaneNamed: #first.
> tmpBrowser transmit to: #first; andShow: [:a |
> a graphET
> title: 'First Chart with ET';
> chart: [:chart :mooseModel|
> chart verticalBarDiagram
> models: (1 to: 3);
> xAxisLabel: 'Test label';
> yAxisLabel: 'Another';
> regularAxis.
> ].
> ].
> tmpBrowser openOn: 1
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
It seems we should update the Magritte and OSProcess dependencies:
- Loading Magritte seems to load a wrong version of Grease that has a conflict with RPackage
- OSProcess was published on MetacelloRepository
It would be great if anyone would take a look at this, and then we can re-snapshot a Moose 4.8.1.
Cheers,
Doru
--
www.tudorgirba.com
"It's not how it is, it is how we see it."
Hi,
I was at ESUG last week and I discussed about this issue with some people, and in the end Stef told me "drop a mail in the mailing list, I am interested to understand what all the other people think about it". So, here I am.
I have my project in which I am modeling development sessions. Each session object has a number of meta-data (e.g., start, end time, etc.) and a collection of events. Each event object owns some meta-data and some references to classes that were "touched" by a given event (i.e., now I am using the Ring definition of the classes, since I plan to serialize and deserialize them and I cannot serialize the real class object, it would be too heavy, isn't it?).
Now the question: I would like to create a Moose model of a development session to be able to import the sessions in the Moose panel and play around with the excellent Moose tool-suite. How should I proceed? Do you think it's better to annotate and add pragmas to the existing classes or to create a minimal parallel hierarchy of my model (i.e., MooseSession for MySession) and have something like MySession>>#asMooseDef which returns an object of kind MooseSession?
Thanks in advance,
Roberto
Hi all,
as quickly reported before, there is a memory leak in Roassal. I have a reproducible case that shows this behavior when having popups. This is simply using the Easel and the examples present there. I am convinced that a similar problem exists when context menus are used, but the Easel does not have such an example, apparently, so I do not include one. I hope this one example is enough to be able to find the issue for both cases.
How to reproduce:
Paste the following code in a Workspace in the 4.8 release. (Thanks to Alex for the last line ;-) )
Smalltalk garbageCollect.
Smalltalk garbageCollect.
{ ROPopup . ROElement . ROAnnouncer . ROBox . ROLabel } collect: [:c | c allInstances size]
Print-it of this code after each step below, you should get the numbers that I pasted as well.
Step 1: Do nothing
#(0 0 0 0 0)
Step 2: Have Easel showing ROExample>>ClassHierarchy
#(0 235 293 47 204)
S3: Close the Easel
#(0 235 293 47 204)
This for me is already strange. I would expect it to go back to the numbers of Step 1, i.e. zero of everything.
S4: Save-quit image, reopen (just in case there is some magic)
#(0 235 293 47 204)
S5: Show ROExample>>ClassHierarchy, close Easel
#(0 235 293 47 204)
I repeated S5 a number of times. The numbers are the same. So at least we have a steady state, that's not really an issue.
S6: With Easel showing ROExample>>punchChart
#(15 267 307 76 207)
S7: After closing Easel
#(15 267 307 76 207)
Nothing got collected.
S8: With Easel showing ROExample>>punchChart
#(30 300 342 101 224)
S9: After closing Easel
#(30 300 342 101 224)
Again nothing got collected.
S10: With Easel showing ROExample>>punchChart
#(45 333 377 126 241)
S11: After closing Easel
#(45 333 377 126 241)
(and so on). This is a big issue for me, because I have a lot of popups in AspectMaps, and a lot of re-executing the visualization script. I effortlessly get to images of 300+ megs this way, when starting from 50 megs before starting to visualize things.
Hope this helps in finding the bug,
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD lab - Computer Science Department (DCC) - University of Chile
First, THANKS FOR BREATHING NEW LIFE INTO SMALLTALK!!!!!
We've adopted Pharo/Moose/et.al. for a major project in IBM Research, and
as a 29-year Smalltalk veteran, I am simply blown away by all the extreme
functionality the community has developed.
In getting used to Glamour, I found a need for a doubleClick action, but
the only examples and APIs I could locate used the transmission to update
another pane. I worked out how to do what I need using a "hidden pane",
but its an awkward hack. What I would really like is a strongSelectionAct:
but I haven't learned enough of the infrastructure to add it myself.
I also found that once you doubleClick an unselected list item, it launches
the action, selects the list item, but then you can't doubleClick it again
for another action. I found a solution by resetting the port value.
Here's the code that works.
browser := GLMTabulator new.
browser row:#numbers; row:#numbersDoubleClick size:0.1.
browser transmit to: #numbers; andShow:[:a| a list display:[:n| 1to:
n]].
browser transmit to: #numbersDoubleClick; from: #numbers
port:#strongSelection;
andShow:[:x| (browser portValueAt: (#numbers->
#strongSelection)) explore.
browser portValueAt: (#numbers->
#strongSelection) put: nil].
browser openOn: 10.
Is there a better way?
Regards,
Sam
Sam S. Adams, CTO - Contextual Computing
IBM Distinguished Engineer, IBM Research
Mobile: 919-696-6064, email: ssadams(a)us.ibm.com
Assistant: Linda R. Morrison. (720) 395-0460 Fax: (845) 491-4318, Tie:
676-0460, linda.r.morrison(a)us.ibm.com
<<Hebrews 11:6, Proverbs 3:5-6, Romans 1:16-17, 1 Corinthians 1:10>>
Hi,
I now snapshotted the current version as Moose 4.8 and pushed it to the
Pharo 2.0 metacello repository. Together with this, I also snapshotted:
ConfigurationOfMooseAlgos->'2.4-snapshot'.
ConfigurationOfFame->'1.3-snapshot'.
ConfigurationOfPetitParser->'1.7-snapshot'.
ConfigurationOfMondrian->'2.10-snapshot'.
ConfigurationOfEyeSee->'1.1-snapshot'.
ConfigurationOfRoassal->'1.428-snapshot'.
ConfigurationOfGraphET->'0.2-snapshot'.
ConfigurationOfGlamour->'2.5-snapshot'.
ConfigurationOfGToolkit->'0.6-snapshot'.
ConfigurationOfMoose->'4.8-snapshot'
Please take a moment to test that things load properly in your image and
let us know both if it works and if it does not. We will announce the
release officially ideally today.
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"