Moose-dev November 2013

moose-dev@list.inf.unibe.ch

31 participants
160 discussions

Re: Pharo 3 / Torch
by Stephan Eggermont 12 Nov '13

12 Nov '13

Martín wrote: >I'm interested in the current state of your migration of Torch. Any news after this email? I haven’t looked further. Blocked at the changes in AST-Semantic. I didn’t understand what the replacement code in OPAL is supposed to be, and didn’t get enough detailed responses then. Stephan.

2 1

moose 5 plan
by Tudor Girba 12 Nov '13

12 Nov '13

Hi, It is time to set the goals for the next couple of releases. I would like to release a Moose 5.0 together with Pharo 3.0, and release another 5.1 a couple of months later. This spring, I laid out the following roadmap: http://www.humane-assessment.com/blog/moose-5-0-roadmap A couple of the targets have already been matched: - we have already removed Mondrian - Roassal works with Athens in the Moose image Next would be to completely replace EyeSee with Graph-ET. Daniel, are you still around? Otherwise, is anyone interested in participating in this project? I know that Jan is working on islands in PetitParser and he promised to release his code sometime soon :). Is anyone interested in the Fame+Traits project? How about continuing the Moose on web one? Other than that, I am now interested in rethinking the user interface almost from the ground up. This project would work hand-in-hand with the Glamorous Toolkit project. However, I need help. Specifically, I would need people that are interested in building widgets in Morphic. Any takers? Do you have other interests and plans? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

6 6

Re: moose 5 plan
by Stephan Eggermont 12 Nov '13

12 Nov '13

We hope to finish PetitDelphi soon. Not having a language specification doesn’t help with estimation. >> Is anyone interested in the Fame+Traits project? We will at least take another look at memory consumption of FAMIX models. I’d like building some morphic widgets, but want to prioritize PetitDelphi. Stephan

1 0

FAME not ensuring
by Yuriy Tymchuk 12 Nov '13

12 Nov '13

Hi. So if I’m not mistaken _ensure_ is meant to create referred data if it’s missing. But when you look at: ensureClass: var var isBehavior ifTrue: [ ^classDict at: var ]. var isSymbol ifTrue: [ ^classDict at: (self class environment at: var) ifAbsent: [ metaDict at: var asString ]]. var isString ifTrue: [ ^metaDict at: var ]. [ false ] assert. it’s not ensuring anything. Isn’t there supposed to be something like: metaDict at: var asString ifAbsent: [ self processClass: var asClass ] This really frustrates me about FAME. You cannot tell it "someObj asMSE”. You have to write a tons of pragmas, then do some shenanigans with metamodels and only then you can get serialisation working. Looks like stone age. Sorry for jumping on all the things like that, it’s just that Moose - related things remind me of Java… Uko

3 4

Re: Issue 53 in moose-technology: [FAMIX3] round-trip extraction/generation test with Fame
by moose-technology＠googlecode.com 12 Nov '13

12 Nov '13

Updates: Status: WontFix Comment #4 on issue 53 by tu...(a)tudorgirba.com: [FAMIX3] round-trip extraction/generation test with Fame http://code.google.com/p/moose-technology/issues/detail?id=53 This issue is too old -- 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

1 0

3 issues changed in moose-technology
by moose-technology＠googlecode.com 11 Nov '13

11 Nov '13

Updates: Status: WontFix Comment by tu...(a)tudorgirba.com: Mondrian is obsolete. Affected issues: issue 400: Local node lookup should stay local http://code.google.com/p/moose-technology/issues/detail?id=400 issue 402: Layout should be aware of parent size / resize http://code.google.com/p/moose-technology/issues/detail?id=402 issue 657: Mondrian progressBar by default http://code.google.com/p/moose-technology/issues/detail?id=657 -- You received this message because you are listed in the owner or CC fields of these issues, or because you starred them. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Re: Issue 325 in moose-technology: #toSelect port
by moose-technology＠googlecode.com 11 Nov '13

11 Nov '13

Updates: Status: WontFix Comment #1 on issue 325 by tu...(a)tudorgirba.com: #toSelect port http://code.google.com/p/moose-technology/issues/detail?id=325 (No comment was entered for this change.) -- 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

1 0

Re: Issue 311 in moose-technology: CAnalyzer create two FAMIXGlobalVariables for the same variable declared two times in a file
by moose-technology＠googlecode.com 11 Nov '13

11 Nov '13

Updates: Status: WontFix Comment #3 on issue 311 by tu...(a)tudorgirba.com: CAnalyzer create two FAMIXGlobalVariables for the same variable declared two times in a file http://code.google.com/p/moose-technology/issues/detail?id=311 I guess this is not an active project anymore. I mark it as won't fix. -- 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

1 0

Re: Issue 308 in moose-technology: CAnalyzer never retrieve the declaredType of a function
by moose-technology＠googlecode.com 11 Nov '13

11 Nov '13

Updates: Status: WontFix Comment #1 on issue 308 by tu...(a)tudorgirba.com: CAnalyzer never retrieve the declaredType of a function http://code.google.com/p/moose-technology/issues/detail?id=308 I guess this is not an active project anymore. I mark it as won't fix. -- 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

1 0

Re: Issue 435 in moose-technology: Using RoelTyper for a better precision of method invocation
by moose-technology＠googlecode.com 11 Nov '13

11 Nov '13

Updates: Labels: Component-SmalltalkImporter Comment #4 on issue 435 by tudor.gi...(a)gmail.com: Using RoelTyper for a better precision of method invocation http://code.google.com/p/moose-technology/issues/detail?id=435 It seems that RoelTyper does not work for all classes. Try this code for getting the classes that raise an error: classes := Dictionary new. Object withAllSubclassesDo: [:each | [(TypeCollector typeInstvarsOfClass: each )] on: Error do: [:error | classes at: each put: error ]]. classes inspect

1 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev November 2013