LEKtrek is "a software development platform for electrical power
applications". This is my masters project to provide the GUI for
modeling electrical power networks, into which researchers can plug
calculations.
These video presentations are still a work in progress, but just in case
you needed some filler for the Show Us Your Project sessions at
PharoConf/MooseDay, please feel free to use any portion of the three
videos listed below. These can be viewed using VLC. Note that the 020
video was the first I ever produced and suffers a little for quality
until I can fix it after writing up my dissertation. Quality gets
better in the later videos 010 and 030.
http://files.openinworld.com/LEKtrek/
* LEKtrek 010 Introduction 2013-02-25.mp4 - 6min - background context
for the project
* LEKtrek 020 Explorer User 2013-02-28.mp4 - 8min30 - a tool to explore
the IEC 61970 Common Information Model (of electrical power networks)
* LEKtrek 030 Modeller User 2013-03-19.mp4 - 9min - a tool for modeling
an electrical power network, and executing calculations on that model.
The project is based on top of Roassal, Glamour & Magritte 3. It will
released open-source, but I am still musing over the finer points of
several licenses, which waits on completion of my dissertation.
Any and all feedback on contents and aesthetics are welcome.
cheers -ben
Hi!
Roassal is now in SmalltalkHub. Although this is a happy news, being in SmalltalkHub completely disrupts the way we work here. Versionner does not run on Pharo 2.0, which means we cannot version Roassal (and the tools we planned to migrate to SHub) the way we have done up to now.
An easy fix to this is to use Pharo 1.4 to do the saving (I do not mind to do it until Versionner works on Pharo 2.0). How can Gofer be updated? In Pharo 2.0 Gofer supports some methods that do not exist in Pharo 1.4.
Another fix, is that we continue to work on squeaksource, and do some update time to time of SHub.
@Christophe: what is needed to have Versionner working on Pharo 2.0.
All our tools are properly versioned with a complete history. We cannot jeopardize this.
This is not a good surprise.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Doru,
Do you think it can be worthwhile idea to propose a project in GSoc to port
glamour on the web with Amber? I know that there is already an effort with
Seaside but I am just thinking aloud.
A+
Usman
Hi,
One of the Moose test runs a visualization that manipulates CompiledMethods, and it runs into an error when trying to find an entry inside a dictionary that has compiled methods as keys. In the end, I managed to isolate the problem that can be reproduced by:
1. Download the moose image:
https://ci.inria.fr/moose/job/moose-latest-dev-4.8/lastSuccessfulBuild/arti…
2. Execute:
(MooseIncomingQueryResult>>#selectDependencies:) = (MooseOutgoingInvocationQueryResult>>#selectDependencies:).
It seems it is a Pharo problem, or something related to these particular methods. Would anyone be interested in looking into this?
Cheers,
Doru
--
www.tudorgirba.com
"Obvious things are difficult to teach."
Hi,
I added this in ConfigurationOfMoose>>baseline48:
package: 'Moose-RoassalPaintings' with: [
spec requires: #('Roassal' 'Famix-Extensions') ];
However, the thing with menuMorphBlock: is that it is mainly used in combination with mooseMenuMorph:
view interaction menuMorphBlock: [ :element | element mooseMenuMorph ].
As such, what we need is a different method that should replace mooseMenuMorph: and that populates the Roassal menu with Moose actions. For example, for Glamour we have mooseFinderActions. Perhaps we can add something in the direction of mooseRoassalActions.
Cheers,
Doru
On Mar 27, 2013, at 8:16 PM, Juraj Kubelka <me(a)juraj-kubelka.cz> wrote:
> Hi,
>
> I have created new package Moose-RoassalPainting in Moose/main repository.
> The package Moose-DistributionMap-JurajKubelka.43 requires Moose-RoassalPainting-JurajKubelka.2.
>
> I do not know how to maintain dependencies. Please, would you, Doru, revise it and explain me (or do) the changes of configuration?
>
> Thanks a lot,
> Jura
>
>
> On 25.3.2013, at 16:21, Juraj Kubelka wrote:
>
>> Hi all,
>>
>> Today Alexandre Bergel and I worked on Moose-DistributionMap. In the method AbstractDistributionMap>>open we used ROMondrianViewBuilder instead of MOViewRenderer.
>>
>> There is method MOAnnouncer>>menuMorphBlock: which is used several times in code (e.g. AbstractDistributionMap>>renderOn:).
>>
>> 1. Do we need this method? Can I replace it with other techniques?
>>
>> 2. If I should keep it that way, I would like to see MOAnnouncer>>menuMorphBlock: in Morphic (Pharo) related package in order to keep Roassal "dialect free".
>>
>> Can someone give me some ideas about the best replacement or an introduction why it is that way?
>>
>> Thanks,
>> Jura
>
--
www.tudorgirba.com
"Value is always contextual."
Hi!
In papers, I usually refer to moose with the moose website. The paper that describes moose are rather old.
Doru, does your book has an ISBN number?
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Just a reminder: if you plan to attend PharoConf and/or MooseDay, please register as soon as possible.
Cheers,
Doru
Begin forwarded message:
> From: Tudor Girba <tudor(a)tudorgirba.com>
> Subject: [Esug-list] pharoconf | mooseday | 2013 - call for participation
> Date: March 17, 2013 8:56:41 PM GMT+01:00
> To: Moose-dev Moose Dev <moose-dev(a)iam.unibe.ch>, "Pharo-project(a)lists.gforge.inria.fr Development" <pharo-project(a)lists.gforge.inria.fr>, A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr>, ESUG Mailing list <esug-list(a)lists.esug.org>, Seaside - general discussion <seaside(a)lists.squeakfoundation.org>, vwnc nc <vwnc(a)cs.uiuc.edu>
>
> (please distribute)
>
> We are happy to invite you to the PharoConf | MooseDay | 2013:
> http://scg.unibe.ch/wiki/events/pharoconf-mooseday-2013
>
> The conference will take place at the University of Bern during April 2-4:
> - PharoConf (April 2,3)
> - MooseDay (April 4)
>
> The conference will be free and will even include a free lunch. Yes, free lunch. No trick.
> We only kindly ask you to register online for each event as soon as possible.
>
> STUDENT SPONSORSHIPS:
>
> ESUG will sponsor the travel of up to 10 students with 150 EUR / person.
> Please apply for sponsorship by mail at esug-info(a)esug.org. First-come, first-served.
>
> The conference sponsors will sponsor the travel of up to 10 students with up to 200 CHF / person.
> Please apply for sponsorship before the conference by mail at tudor(a)tudorgirba.com. First-come, first-served.
>
> IMPORTANT
> If you are a student, please bring your student cards with you to help us limit the lunch costs.
>
> Cheers,
> The organizers
> _______________________________________________
> Esug-list mailing list
> Esug-list(a)lists.esug.org
> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
--
www.tudorgirba.com
"Next time you see your life passing by, say 'hi' and get to know her."
Hi all,
Today Alexandre Bergel and I worked on Moose-DistributionMap. In the method AbstractDistributionMap>>open we used ROMondrianViewBuilder instead of MOViewRenderer.
There is method MOAnnouncer>>menuMorphBlock: which is used several times in code (e.g. AbstractDistributionMap>>renderOn:).
1. Do we need this method? Can I replace it with other techniques?
2. If I should keep it that way, I would like to see MOAnnouncer>>menuMorphBlock: in Morphic (Pharo) related package in order to keep Roassal "dialect free".
Can someone give me some ideas about the best replacement or an introduction why it is that way?
Thanks,
Jura
Dear all,
We are happy to announce that Object Profile will sponsor four months of engineering work around Moose. Juraj will soon send his first email to the mailing list.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Project duration: 4 months, from March 25th, 2013 until July 31st, 2013.
Context:
Mondrian is a visualization engine that has been used by the Moose community since 2008 (since 2006 in VisualWorks). In 2011, Roassal has been proposed as an appealing alternative. Roassal offers a large set of interactions and animations facilities. Currently, Moose remains tied to Mondrian in many part of it, despite the fact that Roassal is largely compatible with Mondrian. The goal of this project is to completely remove Mondrian from the Moose platform.
Objectives:
- Analyzing where and how Mondrian is still used.
- Identifying part of Moose that should be migrated, removed or marked as obsolete
- Provide a replacement of the MOFormBuilder from Mondrian (which is used by Class blueprint for example)
- Complete the migration by removing Mondrian from Moose
- Adding scrollbar to Roassal
- Satisfy unexpected need raised from this migration
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Cheers,
The object profile crew
-= http://ObjectProfile.com =-
Camillo wrote:
>OK will test first to get a decent setup.
That is a good idea (for all presenters). If you can make it into
a 30 second teaser, or even a 6:40/20slide pecha kucha,
we could even publish them already.
Doru: will there be a default presentation machine with screenflow?
Sabine wrote:
>I was planning to record some sessions for my privat use.
>So, I would like to help.
>My cam is a Kodak play sport. If someone has better equipment I can also use
>that.
A multi-cam setup would be great. Being able to switch from question to answer
view helps. That would require one camera to be in front/to the side,
facing the public. I don't know how practical that is with the available room
(and camera zoom).
Stephan
Doru wrote:
>Any volunteers? In any case, I think we can find some on the spot.
Even though we can, I'd prefer it if those being there would take
a look at the program and speak up on which session they would
like to record themselves. That way you can make sure you can
have your full attention to the sessions you need to see (because
when you are recording, you tend to focus on other things than the
story being told).
Camillo wrote:
>I think I will have to use my own machine for the commandline presentation
>(custom terminal font and co..) and I don't have screenflow.
Ah, it works on my machine :)
>Do you think it will work if I do a screen recording using Quicktime?
Yes, Screenflow can import quicktime recordings. Just make sure to
use a sensible format, as both enormous files and bad image quality
are annoying. Synchronisation is no problem. ScreenFlow just allows
after-the-fact highlighting/zooming/panning etc.
Cheers,
Stephan
Hi,
Thanks Alex. We should update the ConfigurationOfMoose.
Cheers,
Doru
On Mon, Mar 25, 2013 at 5:06 PM, Alexandre Bergel
<alexandre.bergel(a)me.com>wrote:
> Hi!
>
> We've just completed the migration of Roassal to SmalltalkHub.
>
> -=-=-=-=-=-=-=-=-=-=-=-=
> Gofer new
> smalltalkhubUser: 'ObjectProfile' project: 'Roassal';
> package: 'ConfigurationOfRoassal';
> load.
> (Smalltalk at: #ConfigurationOfRoassal) project lastVersion load.
> -=-=-=-=-=-=-=-=-=-=-=-=
>
> Interestingly, I have a folder weighting 152Mb of all the versions of
> Roassal. Hard to believe it weights so much :-)
>
> Doru, we haven't changed yet the #development tag. I would like to know
> first whether there is an impact on the way we develop (especially with
> Versionner).
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
--
www.tudorgirba.com
"Every thing has its own flow"
Hi,
Diego will take my video camera with him, making it possible to record the
presentations, so we can put them online. He does not want to spend
three days only recording talks though. He would like some volunteers
to record one (or more) sessions each. Any takers?
The idea is to just keep the camera zoomed in on the speaker.
Slides can be separate. Could a tripod be provided locally?
That would be much more comfortable and better for the quality
of the recordings. Will there be enough light on the presenter to
make it worthwhile, or will the room be dark for the beamer?
If the machine with the presentation has ScreenFlow, it would
be possible to merge the video stream with the presentation
and get really slick results. I would be willing to do the editing.
Cheers,
Stephan
Hi!
Maybe the link https://ci.inria.fr/moose/ can be made apparently on the main page moosetechnology.org ?
I always have a hard time finding it.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Status: New
Owner: ----
Labels: Type-Defect Priority-High Component-Glamour Milestone-4.8
New issue 921 by tu...(a)tudorgirba.com: TextPresentation should override
default shortcuts
http://code.google.com/p/moose-technology/issues/detail?id=921
For example:
composite := GLMCompositePresentation new.
composite wrapper show: [ :a |
a text
act: #inspect on: $d entitled: 'Inspect';
act: #inspect on: $a entitled: 'Inspect';
act: #inspect on: $s entitled: 'Inspect' ].
composite openOn: '123'
It works in Pharo 1.4, but not in Pharo 2.0. The reason is due to the hack
that worked only in Pharo 1.4. Perhaps we need to properly use Keymapping
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
Hello,
Does FAME allow to create one-to-one relationship with automatic update of
the back links? So far, I have seen two entities FMMultivalueLink
(one-to-many) and FMMultiMultivalueLink (many-to-many) and their examples.
I have an elements and its behavior in separate entities and I would like
to create and update one-to-one links between these two entities. I
haven't found any example in Moose.
tx,
Usman
hi!
I'm totally new to smalltalk, although I've heard of it since a lot of time
ago.
In my arch linux installation, I've found some dificulties running squeak,
so I went into pharo once I've discovered they are two free implementations
of smalltalk.
Then I wondered myself, How can I do now to put moose into here ? And then
I saw that by selecting the proper text in one of the default windows that
pharo opens for me, I could have moose (and other subsystems) installed in
the image I'm workin on. So I did.
I've found myself pretty impressed at the ease by which the subsystems get
installed. I started installing one of the web development systems, and I
got thru the whole automated process without any problems.
Then I evaluated the code that installs moose. It started running, and run
a lot without a problem too. But at some point, some missing methods poped
up a window in which I'm asked what to do. At the firsts of them, I put
'proceed' (because I wouldn't abandon, nor debug because I woudn't know
what to do), and it proceeded. At some later pop up errors, I was offered a
fourth option namely 'create', I did, and put the method I was asked to put
somewhere in systembase or some similar name (I can be more precise if
needed or asked to), then a code that showed a 'to be implemented' dummy
method or something, and then again, asked to proceed, and and did this
process a number of times, until I realized that there were many of them,
and I abadoned. And went here, asking for some kind help of you.
I could insist with squeak if that would do better, or go Cuis
alternatively (but from what I've read, maybe Cuis would not fit).
I've also read that pharo support from moose is in some development phase.
Is that true? So if I'm a beginner I should try it until it's ready.
I'm interested in moose mainly, and derived from this, in smalltalk and in
any of its free versions if they work.
Any hint is welcome.
cheers
Haroldo
Hi,
Moose 4.8 works on Pharo 2.0. The only problem I noticed is that CMD+s does not work in the text areas anymore.
So, before we start doing major things (such as removing Mondrian, redoing EyeSee on top of Roassal, adding Athens support, adding Traits into FAMIX, or enhancing GToolkit), I have a little proposition.
After a bit more testing I would like to release 4.8, and then move Moose 5.0 to Pharo 3.0 as soon as possible.
Here is why:
- Moose can benefit from enhancements from Pharo, and we can only influence and contribute if we work closely with the Pharo latest version
- Moose should offer tools for Pharo development
- We are a small community that should work more closely together
What do you think?
(If you disagree, please also indicate the amount of effort you would like to invest in Moose in the near future)
Cheers,
Doru
--
www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
Hi,
Given that we want to adopt Athens in the near future, I put together a job that builds Athens on top of Moose:
https://ci.inria.fr/moose/job/moose-latest-dev-extras/
Expect this experimental image to grow a bit once Bifrost will be ported to 2.0.
Cheers,
Doru
--
www.tudorgirba.com
"Innovation comes in the least expected form.
That is, if it is expected, it already happened."
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 845 by google....(a)ben.coman.com.au: some Roassal layouts broken
when nested
http://code.google.com/p/moose-technology/issues/detail?id=845
The application I am developing needs to apply layouts to nested elements.
I noticed that some layouts did not work when nested - so I've done a full
review of the layout listed in ROMondrianExample>>chooseLayoutOn: as per
the attached image. On the left is the non-nested-result and on the right
is the nested-result. I have attached the mcz with a slightly modified
#chooseLayoutOn: as well as #chooseLayoutNestedOn: for comparison.
Attachments:
Roassal-BenComan.313.mcz 241 KB
ROMondrianExample-chooseLayoutNestedOn.png 127 KB
>From lurking at the vm-dev list, it looks like there are quite a lot of problems
in the vm that could be solved by doing some humane assessment.
Was Moose ever used on the vm?
Stephan
Hi guys
I migrated XMLParser, XMLWriter, Pastell to SmalltalkHub and revisited their complete configurations.
Now I will do the same for OPAX.
After I will suggest to put OPAX in readonly and to mention it on the squeaksource web site.
Stef