Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

by Chris Cunningham

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

11 years, 6 months

FAST in 5

by Yuriy Tymchuk

So FAST is all green on Moose 5. https://ci.inria.fr/moose/view/FAST/ When are we going to integrate is with Moose? Cheers. Uko

11 years, 6 months

Jenkins build is back to stable : moose-5.0 #69

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-5.0/69/>

11 years, 6 months

moving moose to pharo 3.0

by Tudor Girba

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"

11 years, 6 months

Re: moving moose to pharo 3.0

by Stephan Eggermont

PetitDelphi had a smooth migration path, 0 changes were needed Stephan

11 years, 6 months

Peek

by Diego Lont

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

11 years, 6 months

Build failed in Jenkins: moose-5.0 #59

by admin＠moosetechnology.org

11 years, 6 months

fixing tests of DSM: ConfigurationOfMoose

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

11 years, 6 months

jenkins jobs on pharo 3.0

by Tudor Girba

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"

11 years, 6 months

Build failed in Jenkins: moose-5.0 #38

by admin＠moosetechnology.org

11 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