Moose-dev May 2013

moose-dev@list.inf.unibe.ch

29 participants
196 discussions

Hapax/CodeFu changes and example script
by Hernán Morales Durand 03 Oct '13

03 Oct '13

Hi guys, For those working in information retrieval, for example for doing td-idf ranking, you can find adapted packages: "Hapax" and "CodeFu" in the BioSmalltalk repository http://ss3.gemstone.com/ss/BioSmalltalk.html . I have translated some VW specific code to Pharo 1.4 (under Windows requires the ProcessWrapper package) and adapted some Hapax methods to work with corpus in different languages. This is an example script for a corpus in Spanish: | corpus tdm documents | corpus := HXSpanishCorpus new. documents := 'el río Danubio pasa por Viena, su color es azul el caudal de un río asciende en Invierno el río Rhin y el río Danubio tienen mucho caudal si un río es navegable, es porque tiene mucho caudal'. documents lines doWithIndex: [: doc : index | corpus addDocument: index asString with: (Terms new addString: doc using: CamelcaseScanner; yourself)]. corpus removeStopwords. corpus stemAll. tdm := TermDocumentMatrix on: corpus. Feel free to integrate to any repository. If you want to add a language just see methods with selectors including "spanish". Cheers, Hernán

5 8

Issue 714 in moose-technology: VerveineJ does not produce correct values for classes in annotation instances
by moose-technology＠googlecode.com 23 Aug '13

23 Aug '13

Status: New Owner: ---- CC: anquetil...(a)gmail.com Labels: Type-Defect Priority-High Component-VerveineJ New issue 714 by tudor.gi...(a)gmail.com: VerveineJ does not produce correct values for classes in annotation instances http://code.google.com/p/moose-technology/issues/detail?id=714 Take a look at the example below: @XmlElement(name = "Time", required = true, type = String.class) protected Date time; The value of the third attribute of the annotation instance is the actual source code of the String class. Instead, it should be just the string 'String.class'. Ideally, we would get an actual reference, but the string would do for now.

2 11

Issue 888 in moose-technology: MondrianViewBuilder should support a better zOrder
by moose-technology＠googlecode.com 13 Aug '13

13 Aug '13

Status: New Owner: ---- CC: alexandr...(a)gmail.com Labels: Type-Enhancement Priority-Medium Component-Roassal New issue 888 by tu...(a)tudorgirba.com: MondrianViewBuilder should support a better zOrder http://code.google.com/p/moose-technology/issues/detail?id=888 Here is a little example: view shape label text: #yourself. view nodes: (1 to: 20). view edges: (1 to: 20) from: [:x | x // 2] to: 1. view edges: (1 to: 20) from: [:x | x // 3] to: 2. view edges: (1 to: 20) from: [:x | x // 5] to: #yourself. view edges: (1 to: 20) from: [:x | x // 7] to: #yourself. view dominanceTreeLayout Open this one is Mondrian and then in the Roassal Easel. Then, try to select 1. In Roassal, you cannot select 1 because of the edges that go on top of it. What is more, you also can barely see it. This situation will always appear in graphs with edges that cross the nodes. Given that at least the MondrianViewBuilder should be about mapping domain models onto graphs, having a sensible zOrder, at least in the MondrianViewBuilder is important.

3 27

Issue 686 in moose-technology: Order in the Mondrian view DSL?
by moose-technology＠googlecode.com 07 Jul '13

07 Jul '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 686 by step...(a)stack.nl: Order in the Mondrian view DSL? http://code.google.com/p/moose-technology/issues/detail?id=686 The order in which the view script has to be build up is not very clear. This is to be documented in http://www.themoosebook.org/book/internals/mondrian/scripting {shape, interaction} < nodes < edges * Type-Review * Component-Mondrian

1 2

Issue 801 in moose-technology: MorphTreeMorph does not properly support custom selection on Windows
by moose-technology＠googlecode.com 07 Jul '13

07 Jul '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Glamour New issue 801 by tudor.gi...(a)gmail.com: MorphTreeMorph does not properly support custom selection on Windows http://code.google.com/p/moose-technology/issues/detail?id=801 Open a MorphTreeMorph and then try to press Alt+Click to select multiple elements. This does not work on Windows (but it works on Mac using Command). However, selecting a range using Shift+Click works just fine.

1 1

Issue 857 in moose-technology: ROCircle strange MNU #extent:
by moose-technology＠googlecode.com 07 Jul '13

07 Jul '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 857 by benjamin...(a)gmail.com: ROCircle strange MNU #extent: http://code.google.com/p/moose-technology/issues/detail?id=857 With ConfigurationOfRoassal.667 just loaded, my project application popped up a 'MNU: receiver of "extent:" is nil, but as you can see in the attached screen snapshot, which has the default debugger highlighting showing the current executiong, the receiver is the ivar 'next' which is actually _not_ nil, but an instance of RONullShape. Strange... As a test case, executing the following in Rossal Easel caused the same MNU. ========= rawView add: (ROElement on: 1) + ROCircle. ========= Fixed it with: Compiler recompileAll. This actually has happened to me a few times in past couple of weeks. (Note actually the example code gives a really tiny circle and #spriteOn: would have been better than #on:) Attachments: ROCircle-MNU-extent.png 34.6 KB

1 9

Issue 800 in moose-technology: Glamour browsers do not respond to browser-global keybindings
by moose-technology＠googlecode.com 02 Jul '13

02 Jul '13

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.

1 4

Issue 853 in moose-technology: ConfigurationOfMoose should be split to reflect core vs suite
by moose-technology＠googlecode.com 02 Jul '13

02 Jul '13

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.

1 2

Issue 913 in moose-technology: MorphTreeTransformMorph>>drawSubmorphsOn: race condition
by moose-technology＠googlecode.com 01 Jul '13

01 Jul '13

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

1 3

Issue 716 in moose-technology: span or size for each column in GLMTablePresentation
by moose-technology＠googlecode.com 01 Jul '13

01 Jul '13

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.

1 2

← Newer
1
2
3
4
5
6
7
8
...
20
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev May 2013