Moose-dev

moose-dev@list.inf.unibe.ch

6630 discussions

by Sean P. DeNigris

GT's browse icon does not match Pharo's (see the world menu), creating an inconsistent feel. In fact, I eventually clicked on the button only out of curiosity. Would it be possible to use whatever the underlying system uses (in this case "Smalltalk tools browser taskbarIcon")? Thanks! ----- Cheers, Sean -- View this message in context: http://forum.world.st/GT-Inspector-Browse-Icon-tp4806062.html Sent from the Moose mailing list archive at Nabble.com.

9 years, 11 months

gtPresentation - #display:?

by Sean P. DeNigris

In experimenting with creating a custom inspector for my domain object, I came across the following intriguing method: Float>>#gtInspectorFloatIn: composite <gtInspectorPresentationOrder: 30> ^ composite table title: 'Float'; display: [ ... {'binary' -> self binaryLiteralString. 'significand' -> self significand. 'exponent' -> self exponent} ]; column: 'Key' evaluated: #key; column: 'Value' evaluated: #value; send: #value While it was easy enough to adapt this to my needs, I found the #display: and #send: sends quite strange. #display: seems like a strange API - like we're using an object designed to do something other than inspect objects; and I wasn't sure what exactly #send: did, my presentation seemed to function the same way with or without it... ----- Cheers, Sean -- View this message in context: http://forum.world.st/gtPresentation-display-tp4806066.html Sent from the Moose mailing list archive at Nabble.com.

9 years, 11 months

How can I package this ?

by Jonathan Wadin

Hello, I made something look likes hives plot that with RTMondrian. For this, I create RTRectLineLayout and RTHivePlot. How can I package this ? Should I create one package Builder-HivePlot ? What do you think about it ? Cheers, Jonathan.

9 years, 11 months

FAMIXType>>incomingAccesses

by Damien Cassou

#flatCollect:. In my case, the variable 'attributes' is of type http://damiencassou.seasidehosting.st FAMIXType>>incomingAccesses ^ self privateState cacheAt: #incomingAccesses ifAbsentPut: [ attributes flatCollect: [ :each | each incomingAccesses ] ] Hi, in this method when the cache is empty, it is initialized with the result of FMMultivalueLink. When sending #flatCollect: to a FMMultiValueLink, the result is an OrderedCollection (because FMMultiValueLink>>#species returns OrderedCollection). This means that it is no more possible to update the list of incomingAccesses. Is that the desired behavior? In my case, this behavior triggers a bug. When the following method is FMMultiValueLink class>>on: element update: selector from: old to: new "refresh the other side of the relations to reflect change in value" old ~= new ifTrue: [ old notNil ifTrue: [ (old perform: selector) unsafeRemove: element ]. new notNil ifTrue: [ (new perform: selector) unsafeAdd: element ]]. ^ new executed while importing a mse, I get a DNU: This is because the (new perform: selector) expression returns an OrderedCollection that does not understand #unsafeAdd: (selector equals to #incomingAccesses). Could somebody help me please? -- Damien Cassou "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

9 years, 11 months

moose and json

by Sebastian Heidbrink

Hi, I man ot sure if this is the right lists to ask such question please let me know if there is a better one. I am currently working my self through the moose book and Glamour chapter. I have a REST interface here that I would like to test and analyze via Moose. I have a json specification of all the apis available. So using a JSON parser in Pharo creates a Array/Dictionary based model representation. I wonder how you go from there? Do you implement the whole data model in Pharo to have a nice NeoJSON support? Is there already a package that genreates Smaltlak classes from Dictionaries? Is there a tool the create MSE files from JSON? Or are you just working with these Array/Dictionary structures? I currently just try to learn to use the Glamour Editor and try to represent the API in a useful way. Any hint, link or advice is very welcome Thanks Sebastian

9 years, 11 months

Agile visualization book as an interactive grafoscopio document

by Offray Vladimir Luna Cárdenas

Hi all, This mail will have two parts, a small first one where I share my advances and little context on the project and the second one, with details where I made specific questions regarding concepts and code and how to make progress. I hope to be fluid and proper balanced and interesting enough to get feedback soon. Context ======= I have made a small video at [1] showing my progress on Grafoscopio[2], a tool for the creation of interactive notebooks for open/citizen/garage science and research (for a better view I recommend to see the video in full screen mode). As you can see, I have a complete outline of the Agile Visualization book stored as a single "ston document" [3], that can be exported to pandoc's markdown [4] and from there to LaTeX, pdf, html, doc, etc. It can contain special tagged nodes and the view and behaviour of them change accordingly to the tag. In the video a node tagged as code is showed as an interactive playground where you can execute an explore the objects deeper. My problem is that this kind of special nodes are not saved, as happens with default nodes and the reason is that the special view (which is a sub-browser) is not wired properly to the rest of the browser and that's why I get a nill value after revisiting the code node in the video. [1] https://archive.org/details/gfcp-alpha-code-exec-but-non-saving.mp4 [2] http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-ini… [3] http://mutabit.com/deltas/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Ag… [4] http://mutabit.com/deltas/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Ag… Details ======= The logic of what I'm doing is something like this: i. When a node in tree at the left is selected, it shows the contents of the selected tree. ii. If something changes in the node content at the right, the changes are automatically updated. iii. If a node is tagged in a special way, a custom browser is called. The code that select which sub-browser to show for a particular tagged node is something like this: ==[a]============================== UI>>buildBrowserNamed: aName "Main method for building the interface for trees and its nodes. The name of the browser corresponds to the name of the file where tree is stored (or is named 'draft.ston' by default)" "... snip" (browser transmit) from: #tree port: #selection; to: #nodeBody; when: [:selection | selection notNil]; andShow: [ :a :node | self bodyIn: a for: node. self body2ForCodeIn: a for: node. self bodyForTransmediaIn: a for: node ]. "... snip" "Creating a self updatable body pane" (browser transmit) from: #tree port: #selection; to: #nodeBody; when: [:selection | selection notNil]; andShow: [ :a :node | self bodyIn: a for: node. self body2ForCodeIn: a for: node. self bodyForTransmediaIn: a for: node ]. (browser transmit ) from: #tree port: #selection; from: #nodeBody port: #text; when: [:node :text | text notNil & node notNil]; to: #nodeBody port: #neverland; transformed: [:node :text | node body: text asString]. (browser transmit) from: #tree; to: #nodeHeader; andShow: [ :h | self headerOn: h ]. (browser transmit ) from: #tree port: #selection; from: #nodeHeader port: #text; to: #nodeHeader port: #neverland1; when: [:node :text | text notNil & node notNil]; transformed: [:node :text | node header: text asString] =================================== The last part of the code is responsible for updating the tree contents automatically with The "body2ForCodeIn: for:" [b] is the responsible for showing the playground by calling a custom browser that is called "panelAsCodeFor:"[c]. Here is their code: ==[b]============================== UI>> body2ForCodeIn: constructor for: aNode "Shows the body of a selected node as executable code." aNode tags = 'código' ifFalse: [ ^self ] ifTrue: [constructor custom: (self panelAsCodeFor: aNode)]. =================================== ==[c]============================== panelAsCodeFor: aNode "Shows an interactive playground for Smalltalk code in a node body" browser := GLMTabulator new. browser title: 'Código'. browser column: #code. browser transmit to: #code; transformed: [ GTPlayPage new content: aNode body ]; andShow: [ :a | a custom: GTPlayground new ]. browser sendToOutside: #nodeBody from: #code -> #text. ^ browser. =================================== So, wiring by "sendToOutside: from:" is not working and I don't know how to tell my code browser to autosave its contents as part of the node body where they belong. Any help with this is appreciated. Cheers, Offray

9 years, 11 months

Re: [Pharo-users] GSOC 2015 application

by Serge Stinckwich

On Wed, Feb 11, 2015 at 3:07 PM, Martin Bähr <mbaehr(a)email.archlab.tuwien.ac.at> wrote: > Excerpts from Serge Stinckwich's message of 2015-02-11 10:02:21 +0100: >> with Uko, we are considering submitting the Pharo project as a >> mentoring organization for GSOC 2015: >> >> We will need your help in order to find ideas of projects. > > Is there any effort make a joint application under esug or some other umbrella? We are under the umbrella of the Pharo Consortium. > there are a few projects on labs.fossasia.org that might fit: > > Create a file editor and asset manager solution with smalltalk > Create a smalltalk application for offline text search > emulate a PostgreSQL server in Smalltalk > Smalltalk SQL Parser & Evaluator > > i also discussed with craig the idea of doing something with his context work on pharo. > essentially i'd like to use context as a tool to remote manage images. > a gsoc project could be to work out how to set up context for that usecase > (while helping to make sure context works with pharo) You are from FOSSASIA ? Didn't know you have some interests in Smalltalk ;-) If some of your projects are related to Pharo, we could post also your projects on our lists. We will send the link to list of ideas in a few hours. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

9 years, 11 months

GSOC 2015 application

by Serge Stinckwich

Dear all, with Uko, we are considering submitting the Pharo project as a mentoring organization for GSOC 2015: http://www.google-melange.com/gsoc/homepage/google/gsoc2015 We will need your help in order to find ideas of projects. Stay tune for more information soon. Thank you. Cheers, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

9 years, 11 months

tree presentation: displayblock and childrenblock

by Nicolai Hess

Why does a displayblock affect the arguments used for accessing the children of the nodes? The following code creates a TreePresentation from the current working Directory: browser := GLMTabulator new. browser column: #tree; column: #text. browser transmit to: #tree; andShow: [ :a | a tree title: 'FS'; "display: [ :item | item basename ];" children: [ :item | item isDirectory ifFalse: [ #() ] ifTrue: [ item children ] ] ]. browser openOn: FileSystem disk workingDirectory. As I don't want to see the FileReference printString, but the name of the File, the first thing I tried is a displayblock like the commented line above. But after this change the children block does not work anymore. The item it calls #isDirectory on, is not the FileSystem entry but the name returned by the display block. #format: instead of #display: works: browser := GLMTabulator new. browser column: #tree; column: #text. browser transmit to: #tree; andShow: [ :a | a tree title: 'FS'; format: [ :item | item basename ]; children: [ :item | item isDirectory ifFalse: [ #() ] ifTrue: [ item children ] ] ]. browser openOn: FileSystem disk workingDirectory May examples from GLMBasicExamples are using #display: , thats why I tried this first. What is the intention to use the display block for accessing the children? nicolai

9 years, 11 months

Re: [Pharo-dev] TROSMTileProvider

by Sven Van Caekenberghe

Thierry, Onil, I rounded up my experiments with a 2nd commit on my experimental branch: === Name: Roassal2-SvenVanCaekenberghe.720 Author: SvenVanCaekenberghe Time: 5 February 2015, 3:40:43.211681 pm UUID: 121ffc22-4a30-4153-bef1-e019a92862bc Ancestors: Roassal2-SvenVanCaekenberghe.719 Experimental branch. Second version. Some more changes after discussing with Thierry @ Pharo Days and hours of experimenting Added TROSMTileProvider>>#cachedTileNamed: and #memoryCachedTileNamed: Rewrote/simplified TROSMShape>>#getTile: to no longer fork a 'get tile' process when the tile is cached in memory or on the file system Removed all hacks trying to optimize the number of times #signalUpdate was called - made no difference. Tried several logging approaches but that did not reveal anything special. The observed slowdown for tiles in the file cache but not the memory cache is still there, even though loading about 10 tiles takes less than 40 ms (see #testEmptyMemoryCacheParisLevel7) === Summary, it should be faster, but it is not. Forking and network downloading are gone, each of about 10 tiles takes less than 4 ms, the total observed slowdown is still about 1 to 2 seconds - with no extra #signalUpdate. I don't know why and I don't understand. I hope somebody can have a look, I feel that we can/should make this better still. Sven > On 28 Jan 2015, at 16:58, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Sven, > > Thanks for the work. I'll have a try (if I manage to get the time) and we'll meet tomorrow for sure :) > > Thierry > > 2015-01-28 14:43 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi Thierry, Onil, > > First let me iterate what I wrote last week, the OSM stuff in Roassal is very cool, very well written. Great work. > > Since I have some experience with OSM maps, tiles and serving them, I had a look to see if I could optimise the tile drawing/loading, which is visibly a bit slow, one would assume because of the loading of the tiles over the network. > > I just committed (based on code that I wrote some time ago): > > === > Name: Roassal2-SvenVanCaekenberghe.719 > Author: SvenVanCaekenberghe > Time: 28 January 2015, 2:31:50.462461 pm > UUID: 0978fb6a-d6d0-4d86-a9ae-1f2f83a0b6a2 > Ancestors: Roassal2-AlexandreBergel.718 > > Experimental branch. > > Introduction of TROSMTileProvider to optimize getting OSM tiles, adds one shared memory cache and a local file system cache, predefines and reuses 6 http clients spread over different hosts. > > Modifies TROSMShape>>#getTile: and adds TROSMShape>>#tileNamed: > === > > The strange thing is though, that I can optimise the loading (as benchmarked separately), but in most cases (not when they are in the memory cache, but when they are in the file cache) the drawing still has the same pauses as before - which I don't understand, at all. But it is a bit hard to explain. > > Anyway, Thierry, I will see you tomorrow and the day thereafter and I hope I can show you what I mean. > > Regards, > > Sven > > >

9 years, 11 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