the contents say:
"Moose 4.8
This distribution was built October 29, 2013.
"
Probably should say 4.9, right?
Also, I find it interesting that the package-cache has the Athens and font
MCZ files in it - was that intentional?
Finally, in the pharo-vm subdirectory, the PharoV10.sources are present.
Which really isn't needed - the PharoV20.sources are in the main directory.
So, this is just another 3.8MB of compressed file that gets passed around.
I'm looking at the moose_suite_4_9-win.zip version of the release.
Not really a complaint, just a set of observations.
Now, off to play with the new version (for a while, before jumping on Moose
5.0).
-Chris
Hi,
We essentially finished moving Moose to Pharo 3.0 (we still have 6 yellow
tests but they needed attention anyway). It took about 4 people looking
into issues for a total probably around 2 man-days of effort. The largest
impediment was actually SmalltalkHub being down for one day :).
What posed problems:
- RB visitor now has correct visit* methods instead of accept* methods. The
deprecation messages helped quite a bit. This meant (1) that we had to
rename in our visitors the methods, and (2) that we had to change the old
accept* messages.
- RB nodes do not answer to #isLiteral anymore. Instead, they answer
correctly to #isLiteralNode so that to avoid confusion with
Object>>#isLiteral. This is good, and this meant that we had to hunt all
#isLiteral usages in Moose.
- Categories are no longer mapped on RPackages through 1-to-1. This is also
good because it is an important step in Pharo. Although originally we said
we want to keep 1-to-1, this is probably a better solution now. For Moose,
this meant that some of our older tests setup had to be modified a bit to
rely on RPackage only.
- Some Morphs rely now on Announcements, and this had a little impact on
the assumptions we make when we suspend announcements (to avoid infinite
loops) that are being sent between Morphic and Glamour. We fixed this in
Glamour.
- In FileSystem #ensureDirectory was renamed to #ensureCreateDirectory
without a deprecation. For this one, we should add a deprecation for the
old method.
- flatCollect had a conflicting behavior in Pharo. We are now integrating
the Moose version so that it returns the same species.
- The new SpecDebugger expects the registered Inspector to be based on
Spec, and this causes problems with the GTInspector. This problem still has
to be fixed in Pharo.
All in all, we encountered no significant problems and the problems we
faced came from deep into Pharo. So, if your code is not relying directly
on RB, RPackage or the Debugger, you are likely to have a smooth transition.
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
Working on Petit Delphi we found a strange implementation for asPetitStream:
Stream>asPetitStream
^ self contents asPetitStream
Further investigation showed that the basic peek was not fast enough for Petit Parser, as it is used a lot. So it implemented a "improved unchecked peek":
PPStream>peek
"An improved version of peek, that is slightly faster than the built in version."
^ self atEnd ifFalse: [ collection at: position + 1 ]
PPStream>uncheckedPeek
"An unchecked version of peek that throws an error if we try to peek over the end of the stream, even faster than #peek."
^ collection at: position + 1
But in my knowledge a basic peek should be fast. The real problem is the peek in the underlying peek:
PositionableStream>peek
"Answer what would be returned if the message next were sent to the
receiver. If the receiver is at the end, answer nil."
| nextObject |
self atEnd ifTrue: [^nil].
nextObject := self next.
position := position - 1.
^nextObject
That actually uses "self next". The least thing one should do is to cache the next object. But isn't there a primitive for peek in a file stream? Because al overriding peeks of PositionableStream have basically the same implementation: reading the next and restoring the state to before the peek (that is slow). So we would like to be able to remove PPStream without causing performance issues, as the only added method is the "improved peek".
Stephan and Diego
Hi!
Apparently ConfigurationOfMoose, the baseline 5.0 loads DSM using the following:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
spec project: 'DSM' with: [
spec
className: 'ConfigurationOfDSM';
file: 'ConfigurationOfDSM';
version: #development;
repository: 'http://www.smalltalkhub.com/mc/Moose/DSM/main' ].
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Shouldn't it be the #default version to load?
I've spent 2 hours because of this :-(
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
I reconfigured all official Moose Jenkins jobs to work with Pharo 3.0:
https://ci.inria.fr/moose/view/Moose%205.0/?
There still are a couple of issues with loading, but the builds do not look
that bad.
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
Who is coming to FOSDEM2014 and is willing to help recording one or more sessions
at the Smalltalk devroom? Instructions and equipment are provided.
Thanks,
Stephan Eggermont
Hi,
i use Roassal graphs in Glamour panes, and i wonder if there is a way to
zoom and center the Roassal graph so that it fits entirely into its Glamour
pane. Can this be done?
Best regards,
Martin.
--
View this message in context: http://forum.world.st/Zoom-to-fit-pane-for-Roassal-tp4716227.html
Sent from the Moose mailing list archive at Nabble.com.
Hi Usman,
Can you try the following example:
R3Example new edgeExample2
There are many many edges displayed and it moves smoothly. On Windows the example goes well. On my machine (MacBookAir), I have an error that appears times to time. If this is the case for you, simply modify the method with:
-=-=-=-=-=-=-=-=-=-=-=-=
R3Morph>>visibleObjectInScreenX: screenX y: screenY
| id |
stateTracker ifNil: [ ^nil ].
^ view
-=-=-=-=-=-=-=-=-=-=-=-=
Here is a screenshot:
https://www.facebook.com/photo.php?fbid=533958193357449&set=a.3411893793009…
Cheers,
Alexandre
On Oct 29, 2013, at 5:59 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
> Hi Usman,
>
> Can you try the following example:
> R3Example new edgeExample2
>
> There are many many edges displayed and it moves smoothly. On Windows the example goes well. On my machine (MacBookAir), I have an error that appears times to time. If this is the case for you, simply modify the method with:
>
> -=-=-=-=-=-=-=-=-=-=-=-=
> R3Morph>>visibleObjectInScreenX: screenX y: screenY
> | id |
> stateTracker ifNil: [ ^nil ].
> ^ view
> -=-=-=-=-=-=-=-=-=-=-=-=
>
> Cheers,
> Alexandre
>
> <Screen Shot 2013-10-29 at 5.41.40 PM.png>
>
> On Oct 21, 2013, at 10:08 AM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
>
>> Hi Alex,
>>
>> Thanx for adding the support for edges in Roassal 3D. I tried and it works.
>> Now, when I try to add several edges (5-10), there is a huge lag and the CPU (~97% mark) and memory utilization of Pharo (~ +300MB) become tremendously high. Which means that I can try things examples but for getting something useful to work would require some memory and load profiling.
>>
>> Can you have a look?
>>
>> Usman
>>
>>
>> On Fri, Oct 18, 2013 at 10:53 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
>> Hi Usman,
>>
>> Sorry for the delay in our answer.
>> We have produced a new version of Roassal3d with a support for edges. Consider this example:
>> -=-=-=-= -=-=-=-= -=-=-=-= -=-=-=-=
>> | view e1 e2 e3 |
>> view := R3View new.
>> e1 := R3CubeShape element.
>> e1 translateToX: 1 y: 1 z: 1.
>>
>> e2 := R3UVSphereShape element.
>> e2 translateToX: -1 y: 1 z: 1.
>>
>> e3 := R3ConeShape element.
>> e3 translateToX: -1 y: -1 z: 1.
>>
>> view add: e1; add: e2; add: e3.
>> view add: (R3LineShape blue elementFrom: e1 to: e2).
>> view add: (R3LineShape blue elementFrom: e2 to: e3).
>>
>> view addInteraction: R3MouseControl new.
>> view open .
>> -=-=-=-= -=-=-=-= -=-=-=-= -=-=-=-=
>>
>> It will produces the following:
>>
>>
>> <Screen Shot 2013-10-18 at 5.53.36 PM.png>
>>
>> Cheers,
>> Alexandre
>>
>>
>> On Oct 14, 2013, at 7:57 AM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I am trying to create a new shape, an edge, in Roassal 3D between two entities. My idea is to draw an edge from the position vector of a source shape to the position vector of a target. The edge is created but not at the correct position, it might be due to the fact that I need to set the position of the edge shape or mismatch between position in Roassal and OpenGL. Can you please have a look?
>>>
>>> Attached with this mail my proposition for the shape that works with the following script.
>>>
>>> |el1 el2 els el3|
>>> view := R3View new.
>>> view camera translateLeft: -2; translateBackward:3.
>>> el1 := (R3CubeShape new color: Color green) element.
>>> el2 := (R3CubeShape new color: Color red) element.
>>> el3 := (R3CubeShape new color: Color cyan) element.
>>> els := { el1. el2. el3 }.
>>> view add: (R3EdgeShape new from: el2; to: el3; size: 1; color: Color blue) element.
>>> view addAll: els.
>>> R3XLineLayout on: els.
>>> view addInteraction: R3MouseControl new.
>>> view open.
>>> <Roassal3d.st>_______________________________________________
>>> 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
>>
>>
>> _______________________________________________
>> 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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Call for Participation in the Smalltalk Devroom at FOSDEM 2014.
http://www.fosdem.org, please forward
" A devroom for the Pharo, Squeak, Amber, GST, Etoilé, Seaside,
Moose Smalltalk projects & Newspeak as derived language.
Smalltalk environments offer a very high development productivity,
unmatched by their successors. Come do some pair programming
with us and experience yourself the advantages of a real OO
environment"
The meetup will take place Saturday, February 1, 2014,
from 9AM until 5PM, building AW. This room has 72 seats,
a VGA video projector and wireless internet.
More information will be available later.
If there are volunteers to record video content, the FOSDEM
organization kindly offered to provide needed equipment & instructions.
Please let me know if you would be willing to spend some
time pointing a camera at a speaker.
Proposals on content and format are welcome.
People interested in running a session should send me an
email at
stephan ( @ ) stack ( dot ) nl
with 'FOSDEM2014’ in the subject and the following information:
- Their name
- The project they are associated with
- A short bio, to be put on the website along with their speaker name
- (optionally) a picture of themselves
- The title of their session (which will go on the website and in the booklet)
- A abstract describing the session in further detail.
- The desired length of the session.
- The desired time slot in which they want to hold the session.
I will send out updates on a regular basis to the lists and anyone
stating his interest.
Suggested values for the duration are 55min, 25min, 6m40 (Pecha Kucha).
The desired time slot is meant to help you prevent conflicts with other dev
rooms in which you might have a talk or your travel arrangements.
There are alternative, non smalltalk-specific tracks available:
lightning talk and the main track
The deadline for submissions is December 31, 23:00 GMT+1.
Devroom related URLs:
http://www.pharo-project.orghttp://www.squeak.org/http://etoileos.com/http://www.seaside.st/http://smalltalk.gnu.org/http://www.moosetechnology.orghttp://amber-lang.nethttp://newspeaklanguage.org/http://www.esug.org
First proposal already arrived:
Stefan Marr proposed:
I could give a presentation on SOM (Simple Object Machine) Smalltalk.
I would especially go into detail of the Truffle-based and the RPython (PyPy) based implementations to show modern ways of language implementations with the goal of achieving high performance.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 914 by cunningh...(a)gmail.com: withCenteredText not centering text
correctly
http://code.google.com/p/moose-technology/issues/detail?id=914
When I ask for centeredText, I would expect it to be centered horizontally
in the area that it is displaying in. Instead, it appears to be bumped up
vertically above the location where it should be.
If you add the following (missing?) method:
ROMondrianExample>>centeredText
"
self new centeredText
"
| view |
view := ROMondrianViewBuilder new.
self centeredTextOn: view.
view open
and then run ROMondrianExample new centeredText, you will see the issue.
How to reproduce the problem: step by step if necessary
This is from the latest (2013-02-14) Moose Suite 4.7 from the
MooseTechnology.org download page, on Windows 7 os.
Labels: Type-Defect Component-Roassal
--
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
Hi Doru,
No problem. I've been using 4.9 development since 4.8 is finished.
When loading older stuff I've had to replace 'mondrian' by 'roassal'
in glamour browsers a few times. Those packages I already committed.
Stephan
Hi,
I am experiencing problems in using #flatCollect: on a SortedCollection.
This reproduces my problem:
((OrderedCollection with: #(1 2 3) with: #(3 4 5)) asSortedCollection: [ :a :b | true ]) flatCollect: #yourself
I am using the last Pharo 2.0 image from the CI server (ZeroConf script).
SortedCollection(Object)>>shouldNotImplement
SortedCollection>>at:put:
WriteStream>>pastEndPut:
WriteStream>>nextPut:
WriteStream(Stream)>>nextPutAll: in Block: [:v | self nextPut: v]
Array(SequenceableCollection)>>do:
WriteStream(Stream)>>nextPutAll:
WriteStream>>nextPutAll:
SortedCollection(Collection)>>flatCollect: in Block: [:each | stream...
SortedCollection(OrderedCollection)>>do:
SortedCollection(Collection)>>flatCollect:
Thanks for any help,
Roby