Moose-dev July 2013

moose-dev@list.inf.unibe.ch

28 participants
130 discussions

by mathieubmddehouck＠mailoo.org

Hi I'm working on Radial tree to make ti take node size into account. I've tried some few things about mixing layout, and it seems to work. (I'll commit it in the week, and send you a mail then) Then I have some questions : If the layout can't change node size, then what can do it ? Is it the aim of Normalizers ?

10 years, 9 months

Issue 800 in moose-technology: Glamour browsers do not respond to browser-global keybindings

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Glamour Milestone-4.7 New issue 800 by tudor.gi...(a)gmail.com: Glamour browsers do not respond to browser-global keybindings http://code.google.com/p/moose-technology/issues/detail?id=800 Essentially, window does not seem to be affected by this line: window on: #keyStroke send: #handleKeyStroke: to: window. This seems to be a Pharo 1.4 related issue.

10 years, 9 months

cleaning issues and preparing for 4.8

by Tudor Girba

Hi, As you might have noticed, I started to go issues that are currently open and see if any of these can be closed. I managed to close a few. I would welcome any of you to join the effort :). And we are due with 4.8. I did not manage last week, but I will try this week. In particular, we would need to deal with this issue: Issue 950: Freeze 4.8 https://code.google.com/p/moose-technology/issues/detail?id=950 Anyone wants to join the effort? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

10 years, 9 months

Issue 853 in moose-technology: ConfigurationOfMoose should be split to reflect core vs suite

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Engineering Priority-Medium Milestone-4.7 New issue 853 by tu...(a)tudorgirba.com: ConfigurationOfMoose should be split to reflect core vs suite http://code.google.com/p/moose-technology/issues/detail?id=853 Right now, in ConfigurationOfMoose we have two methods: - coreDefault - default These should be the basis for splitting into two distinct configuration classes. Ideally, we would rename ConfigurationOfMoose to ConfigurationOfMooseSuite, but this is difficult due to the many scripts that depend on the current name. So, we will not do that (at least not now). Also, in the process of splitting, we will remove the 'default' version and transform it into a baseline.

10 years, 9 months

Re: Improving Roassal Scalability

by Stephan Eggermont

ROView puts its elements in an OrderedCollection, doesn't it? Might using a QuadTree help? Stephan

10 years, 9 months

Re: fast job is broken

by Stephan Eggermont

Johan wrote: >So, yes, stick to the language spec. Some PhD student will be glad for it at some later time! Ok, so that problem we don't have in Delphi. There is no spec, and all available grammars are wrong. AFAIK, most languages have either that problem, or no significant implementations that follow the spec (c++, sql). Chris doesn't seem opposed to a very detailed level, as long as there are some convenience accessors in the right places. Our problem with PetitDelphi is that there is no way to know what nodes to create, without having a usecase for them. So we just started (like Chris, I guess) with what we seemed to need. Stephan

10 years, 9 months

Issue 913 in moose-technology: MorphTreeTransformMorph>>drawSubmorphsOn: race condition

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 913 by benjamin...(a)gmail.com: MorphTreeTransformMorph>>drawSubmorphsOn: race condition http://code.google.com/p/moose-technology/issues/detail?id=913 In my application using Glamour I was often getting a "red square of death". I tracked this down to MorphTreeTransformMorph>>drawSubmorphsOn: where the line "m := submorphs basicAt: row." generates a being a SubscriptOutOfBounds. Part of the cause is that my application is generating update announcements quite fast, but this is also what provided reproducability to be able to track this down. Otherwise this probably only occurs infrequently seemingly at random. I managed to condense this to the following artificial Workspace example. To set up, execute the first three comments (later you can cleanup with the fourth comment), then execute the rest of the script. -------- "Smalltalk at: #TestAnnouncer put: Announcer new ." "Smalltalk at: #TestTree put: (MAContainer new label: 'root')." "Transcript open" "Smalltalk removeKey: #TestAnnouncer ; removeKey: #TestTree" | browser | TestTree := MAContainer new label: 'root'. 1 to: 20 do: [ :x | TestTree add: (MAContainer new label: x) ]. browser := GLMTabulator new. browser column: #one. browser transmit to: #one; andShow: [ :a | a tree updateOn: AnnouncementMockA from: TestAnnouncer ; allExpanded; children: [:x :i | x children ]. ]. browser openOn: TestTree. -------- Then after that has opened, execute the following: ---- [ 10 timesRepeat: [ 101 to: 110 do: [ :y | (TestTree children at: 5) add: (MAContainer new label: y). TestAnnouncer announce: AnnouncementMockA. ]. (TestTree children at: 5) children removeAll . TestAnnouncer announce: AnnouncementMockA. ] ] fork. ---- and the tree list should go red. File in the attached .st file and repeat. Now the tree list doesn't go red. This is likely more an upstream problem with MorphTreeTransformMorph than with Glamour, but Glamour is what I had as my test case. I didn't know how to use MorphTreeTransformMorph directly. I could probably have a go at fixing this myself after some discussion and direction. This was tested in Moose-suite-4-7-beta-20120103. cheers -ben Attachments: MorphTreeTransformMorph-drawSubmorphsOn.st 1.1 KB

10 years, 9 months

Issue 716 in moose-technology: span or size for each column in GLMTablePresentation

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium New issue 716 by jannik.l...(a)gmail.com: span or size for each column in GLMTablePresentation http://code.google.com/p/moose-technology/issues/detail?id=716 I am using GLMTablePresentation, and I would like to specify span or size for each column. To do that: Extend the GLMTablePresenation, and the associated rendering.

10 years, 9 months

Issue 906 in moose-technology: FAMIXType>>classScope should not return nil

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: anquetil...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Famix New issue 906 by tu...(a)tudorgirba.com: FAMIXType>>classScope should not return nil http://code.google.com/p/moose-technology/issues/detail?id=906 Right now, the classScope in FAMIXType returns nil, which is a problem. FAMIXType>>classScope "all types are not classes. Redefined in FamixClass" ^ nil Either we make it return self, or we introduce typeScope.

10 years, 9 months

Issue 897 in moose-technology: Roassal line layout does not work when stretched

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: alexandr...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Roassal Milestone-4.7 New issue 897 by tu...(a)tudorgirba.com: Roassal line layout does not work when stretched http://code.google.com/p/moose-technology/issues/detail?id=897 Try this: view nodes: #(1 2 3) . view horizontalLineLayout stretch We need this to work for the class blueprint

10 years, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev July 2013