Moose-dev February 2015

moose-dev@list.inf.unibe.ch

37 participants
67 discussions

Re: [Pharo-users] GSOC 2015 application
by Serge Stinckwich 11 Feb '15

11 Feb '15

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/

2 1

GSOC 2015 application
by Serge Stinckwich 11 Feb '15

11 Feb '15

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/

2 1

tree presentation: displayblock and childrenblock
by Nicolai Hess 10 Feb '15

10 Feb '15

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

3 3

Re: [Pharo-dev] TROSMTileProvider
by Sven Van Caekenberghe 10 Feb '15

10 Feb '15

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 > > >

2 2

Using "onChangeOfPort: act:" to update data in a browser
by Offray Vladimir Luna Cárdenas 10 Feb '15

10 Feb '15

Hi, I'm reviewing my code, now that I have a better understanding of ports, transmissions and panes. I have nested browsers in my project: a tree that calls a generic node view, but when tagged it calls a custom node view which is a "sub-browser". For this I think that is better to use "onChangeOfPort: act:" instead of the "hacky" way of sending message to #nirvana or #nowhere ports. So, for example I have this minimal example to create a browser: http://ws.stfx.eu/CTGIBTCE70JL How can I change it to use "onChangeOfPort: act:" to update automatically the values in the dict instead of using "to: #values port: #nirvana;"? Thanks, Offray

2 3

transmissions and ports
by Sebastian Heidbrink 09 Feb '15

09 Feb '15

Hi! I am a little stuck. I would like to diplay two lists next to each other. List one displays entries and list two is empty. I would like to be able to select/multiselect entries in list one and make list two update and show these entries. When entries in list one are deselected, they shall be removed from list two again. Is a validator or a transmission/port solution the way to go here? Sebastian

2 3

Glamour and Magritte
by Sebastian Heidbrink 07 Feb '15

07 Feb '15

Is Magritte and Glamour support already supposed to work in the current 5.1 image? My UI is empty. There is only a save and cancel button displayed. I also figured out that the example in the Moosebook seems to be outdated. Description was replaced by magritteDecription, wasn't it? Sebastian

1 1

Auto-updating the browser while changing tags without revisiting nodes on a tree
by Offray Vladimir Luna Cárdenas 06 Feb '15

06 Feb '15

Hi, I'm working on my project Grafoscopio, to provide a outliner/notebook like experience to write and visualize data. Details can be found on [1]. [1] http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-ini… I want to create modal nodes by tagging them, so If I mark a node like code it can behave like a workspace and execute code. You can see a small demo of this feature on [2] [2] https://archive.org/details/grafoscopio-tags-alpha1.mp4 My code for tagging nodes is this: ==[a]============================================= UI>>addTagsTo: a Node "Tags the node passed as argument with a value from the collection of tags available" | selection | tagsAvailable isNil ifFalse: [ selection := UIManager default chooseFrom: tagsAvailable title: 'Elija una etiqueta'. aNode tagAs: (tagsAvailable at: selection) ] ifTrue: [self messageNoTagsAvailable]. browser update. ================================================= But I have three questions: i. How Can I update the nodes views/behaviour without revisiting them? The code in [a] is updating the node trees, but not the particular node views. ii. How can I made the code in a node tagged as "code" get executed? iii. Can I embed playgrounds instead of workspaces in a browser pane, with the possibility to explore objects and get more details about them? Thanks, Offray

2 2

Fwd: Ask Slashdot: What Tools To Clean Up a Large C/C++ Project?
by Ben Coman 06 Feb '15

06 Feb '15

apologies if this post appears twice. The first had the wrong sending address and I presume it will bounce. Maybe a minor opportunity for exposure... http://ask.slashdot.org/story/15/02/05/1354252/ask-slashdot-what-tools-to-c… cheers -ben

1 0

Playing along with Moose :-/ + :-( + "-1"
by Offray Vladimir Luna Cárdenas 06 Feb '15

06 Feb '15

Hi, Today on [1] I read this: """ But, more important than technology is the humane face of Moose. Great ideas come from a state of play in which the current state of facts is taken apart and put together in a new way. That is why Moose is not a fixed thing, but a continuously moving target defined by what the community decides to play with. The only steady concern is to offer at every moment a set of engineered toys and the proper environment for a joyful and perhaps a successful play. All the rest is left for us, the players. """ [1] http://www.themoosebook.org/book/philosophy/research But I feel like playing along with my ideas in Moose. It doesn't matter if I change the way I ask, from time to time my questions get no answer and I revisit the bitter sweet experience of learning Moose. Several weeks ago I asked several questions about Moose. The "+1 consensus" was about asking simpler, so I did. Still I got no answer. I can understand that a direct question to a specific person gets no answer. Hell I'm pretty bad at addressing that questions when are directed to myself from time to time, but an open question for the whole community with only "+1" as the "collective" answer and then silence, even if I try to implement the suggestions for asking in another way can be very... not encouraging. Today I'm still wondering why or how I can't tell a tree to show the contents only if the node is selected, but I get error traces and lost of information by selecting an empty part of the tree to which my custom browser doesn't know how to respond to. Today I'm feeling there is no "us" in "players" for Moose, specially if you're a newbie... only "you" the "single player". :-/ Offray

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev February 2015