May 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [spotter] How do I get all the pragmas of the system?

by Tudor Girba

Hi, This is not provided because that search is too expensive to happen by default. Take a look at the current implementation: GTSpotter>>spotterForPragmasFor: aStep <spotterOrder: 40> aStep listProcessor allCandidates: [ PragmaType all ]; title: 'Pragmas'; itemName: [ :pragma | pragma keyword ]; filter: GTFilterSubstring; wantsToDisplayOnEmptyQuery: false The last statement says that you have to have a query to start the search. And because it is implemented using as a substring filter, you will only get something when you have a letter in the search. Now, if you want to have a full text search option, for example using string match patterns, you can do this: GTSpotter>>spotterForPragmasFor: aStep <spotterOrder: 40> aStep listProcessor allCandidates: [ PragmaType all ]; title: 'Pragmas'; itemName: [ :pragma | pragma keyword ]; filter: GTFilterStringMatch; wantsToDisplayOnEmptyQuery: false Now, if you type #pragma * you get all pragmas The StringMatch is slower than the Substring and that is why we do not use it by default. We still would like to work on a more unified search strategy, but we did not get to it. Perhaps someone else could propose something. Cheers, Doru > On May 21, 2016, at 8:41 AM, stepharo <stepharo(a)free.fr> wrote: > > How do I get all the pragmas of the system with Spotter? > > -- www.tudorgirba.com www.feenk.com "We cannot reach the flow of things unless we let go."

May 21, 2016

[spotter] How do I get all the pragmas of the system?

by stepharo

How do I get all the pragmas of the system with Spotter?

May 21, 2016

Re: [Pharo-users] Panama Papers: a case for reproducible research, data activism and frictionless data (powered by Pharo)

by Offray Vladimir Luna CÃ¡rdenas

Thanks GastÃ³n for your interest. I used csv and imported to sqlite, because that's the way the ICIJ released their info and let me query aggregated information in an easy way. I bridge SQLite with Pharo using UDBC and then the choropleth map was made on Roassal. Details are in the blog post ;-). My first attempt was trying to load all nodes in (Entities in the offshore leaks database) in Roassal and query/visualize directly from it, but with over 150k nodes the environment started to lag and doesn't was as responsive as I want for exploring the dataset. That's why I switched quickly to sqlite. I think that this keeps the environment agile and covers a pretty good amount of the cases when you work with tabular data and even some specific graphs could be replicated from the exported CVS files containing the entities and their relationships. My focus was more on accuracy of the visualization, trying to put the rest of the territories in a Roassal map. If you're interested I can put a quick script to run the visualization/notebook in your Moose image. I have not used Neo4J, but there will be a seminar on how it was used in the Panama Papers next Tuesday: http://info.neo4j.com/0526-register.html Cheers, Offray On 20/05/16 16:42, GastÃ³n Dall' Oglio wrote: > Hi. Looks good :) > > Just out of curiosity, what data format you used? csv, sqlite? > > I am interested in using Neo4j from pharo > (http://smalltalkhub.com/#!/~MasashiUmezawa/Neo4reSt > <http://smalltalkhub.com/#%21/%7EMasashiUmezawa/Neo4reSt>) with a > large database, and few days ago and found the ICIJ used Neo4j to > relate information. In a few days they will give a webinar: > http://info.neo4j.com/05262016-ICIJandPanamaPapersOnDemand_Registration.html > > A question, you can use Neo4reSt to store data and Pharo/Roassal for > display on a more or less friendly way? or there is a lot impedance > between graph models? > > > > 2016-05-20 13:44 GMT-03:00 Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>>: > > Hi, > > I'm glad to share my recent work with Pharo/Roassal in the form of > a minisite[1] and a detailed blog entry[2] arguing about > interactive environments for increasing understanding and > participation in data phenomena: > > [1] http://mutabit.com/repos.fossil/panama-papers/doc/tip/index.html > [2] http://mutabit.com/offray/blog/en/entry/panama-papers-1 > > Using a relatively simple visualization I advocate for this case. > The bigger issues here were not related with visualization, but > with accuracy/completion of the information. For example the > original RTSVGPath includes only 167 world territories, but Panama > Papers mentions over 210. Improving accuracy lead to hunting a bug > and to its bugfix. So we have a more cleaver reader for SVG in > Roassal. I was fighting for several days with newbie errors (like > the one on the download bar not advancing, despite of the download > being made). > > I think that this are good exemplars on how Pharo Roassal is a > superb moldable and affordable platform on the issues of data > oriented reproducible research (in journalism and/or activism and > others). > > Comments and suggestions are welcomed, as always. > > Cheers, > > Offray > >

May 21, 2016

Re: [Pharo-users] Panama Papers: a case for reproducible research, data activism and frictionless data (powered by Pharo)

by GastÃ³n Dall' Oglio

Hi. Looks good :) Just out of curiosity, what data format you used? csv, sqlite? I am interested in using Neo4j from pharo ( http://smalltalkhub.com/#!/~MasashiUmezawa/Neo4reSt) with a large database, and few days ago and found the ICIJ used Neo4j to relate information. In a few days they will give a webinar: http://info.neo4j.com/05262016-ICIJandPanamaPapersOnDemand_Registration.html A question, you can use Neo4reSt to store data and Pharo/Roassal for display on a more or less friendly way? or there is a lot impedance between graph models? 2016-05-20 13:44 GMT-03:00 Offray Vladimir Luna CÃ¡rdenas < offray.luna(a)mutabit.com>: > Hi, > > I'm glad to share my recent work with Pharo/Roassal in the form of a > minisite[1] and a detailed blog entry[2] arguing about interactive > environments for increasing understanding and participation in data > phenomena: > > [1] http://mutabit.com/repos.fossil/panama-papers/doc/tip/index.html > [2] http://mutabit.com/offray/blog/en/entry/panama-papers-1 > > Using a relatively simple visualization I advocate for this case. The > bigger issues here were not related with visualization, but with > accuracy/completion of the information. For example the original RTSVGPath > includes only 167 world territories, but Panama Papers mentions over 210. > Improving accuracy lead to hunting a bug and to its bugfix. So we have a > more cleaver reader for SVG in Roassal. I was fighting for several days > with newbie errors (like the one on the download bar not advancing, despite > of the download being made). > > I think that this are good exemplars on how Pharo Roassal is a superb > moldable and affordable platform on the issues of data oriented > reproducible research (in journalism and/or activism and others). > > Comments and suggestions are welcomed, as always. > > Cheers, > > Offray > >

May 20, 2016

Re: [Pharo-users] StampClient produce only and dealing with heartbeat

by Henrik Sperre Johansen

+1. Testing the RabbitMQ client (very cool, BTW) some time ago (which is structured the same way with a single event loop), I ran into the same kind of issues Holger describes; for example, bursts of incoming data would cause a heartbeat to not be sent in time, and the server would drop connections.* At least at the time, I couldn't see a way to solve those issues in a reliable manner without resorting to using multiple threads** (but never got around to implementing that) Cheers, Henry * There also seemed to be drops related to what the client considered activity that should reset the heartbeat timeout, and what the server seemed to think, but even after (I think) fixing those, I could cause drops by flooding the client with traffic ** Yes, I know, You can configure RabbitMQ to not use heartbeats, but where's the fun in that?? -- View this message in context: http://forum.world.st/StampClient-produce-only-and-dealing-with-heartbeat-t… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 20, 2016

Re: [Pharo-users] StampClient produce only and dealing with heartbeat

by Holger Freyther

> On 19 May 2016, at 10:40, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Holger, Dear Sven, > However, you need a regular opportunity to send something out. Thinking out loud, what about something like > > StampClient>>#runWith: receiveBlock do: sendBlock > > where receiveBlock is like it is now, and sendBlock is called regularly, basically when the loop goes through another cycle, to give you the opportunity to send something, being sure to have exclusive access. > > In the sendBlock you could query your sharedQueue that is being filled by another process, properly MP safe. > > The invocation of #runWith:do: should of course be forked. > > Does that make sense ? It makes sense for my unacknowledged SEND but I see several issues for a general scheme: a.) If write / receive ratio is not equal and I block in the send then I will not receive quickly enough. And if we block on receive (with the *TimedOut) we will not write enough. This is one general architecture issue I seem to circle around[1]. I should not have block one or the other. b.) Integration with ACKed sends (putting a receipt, reading a receipt-id). Is there a generic way to handle it? E.g. I would keep an event in the SharedQueue until it has been acked (and detect timeouts or such). Last but not least. How do you handle the ConnectionClosed and do the re-connect? It seems that >>#runWith: will exit iff ConnectionClosed signal has been raised. Will you respawn the process? Will you create another StampClient and re-execute? sorry, more these are more questions than answers. I have a local client that is similar to >>#runWith:do: (but calls receive from within the send routine). kind regards holger [1] With POSIX/C there is select(), in Windows WaitForMultipleObjects and maybe with erlang the selective receive. Now it is not very object orientated but in pseudo erlang syntax. receive FrameReady -> self handleFrame: arg; FrameToSend -> self writeEvent: arg; Disconnect -> self reconnect. ... after self timeout -> self checkRecvHeartbeatOrSendIt end I could emulate it by spawning multiple processes on "receive", creating a queue, having a semaphore.. but I don't know if I want to limit it to sockets...

May 20, 2016

Panama Papers: a case for reproducible research, data activism and frictionless data (powered by Pharo)

by Offray Vladimir Luna CÃ¡rdenas

Hi, I'm glad to share my recent work with Pharo/Roassal in the form of a minisite[1] and a detailed blog entry[2] arguing about interactive environments for increasing understanding and participation in data phenomena: [1] http://mutabit.com/repos.fossil/panama-papers/doc/tip/index.html [2] http://mutabit.com/offray/blog/en/entry/panama-papers-1 Using a relatively simple visualization I advocate for this case. The bigger issues here were not related with visualization, but with accuracy/completion of the information. For example the original RTSVGPath includes only 167 world territories, but Panama Papers mentions over 210. Improving accuracy lead to hunting a bug and to its bugfix. So we have a more cleaver reader for SVG in Roassal. I was fighting for several days with newbie errors (like the one on the download bar not advancing, despite of the download being made). I think that this are good exemplars on how Pharo Roassal is a superb moldable and affordable platform on the issues of data oriented reproducible research (in journalism and/or activism and others). Comments and suggestions are welcomed, as always. Cheers, Offray

May 20, 2016

Why is split: implemented in the separator rather than the string?

by Andy Burnett

> > > > Message: 1 > Date: Thu, 19 May 2016 20:18:09 -0700 > From: John Pfersich <jpfersich(a)gmail.com> > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] Why is split: implemented in the separator > rather than the string? > Message-ID: <C3F79F22-5675-4E29-97AC-A630D9ADA2E0(a)gmail.com> > Content-Type: text/plain; charset=us-ascii > > If you want to do it reversed, do it like this: > > '1969-07-20' splitOn: '-' > > > Thanks to both of you for responding. Makes sense. Cheers Andy

May 20, 2016

Re: [Pharo-users] Spec layout

by Marion Noirbent

Hi, Thanks, I think i can do it if i take inspiration from your code. I will put too an anotation in the book to correct it. Marion, Le 20/05/2016 00:42, Peter UhnÃ¡k a Ã©crit : > Hi, > > I've made a simple example â see attached fileout. > > Couple things to note: > > 1. >> If i put it on instance side, the lookup don't find it (in the book > Building UI with Spec, it said the lookup begin by the instance side and it > allow to have specific UI, in part about layout) > > As far as I know / as far as I can tell this is false for ComposableModel. > For DynamicComposableModel you can override the method "#layout". > > 2. For some odd reason when you add a new radio button it looks like a > checkbox and only once you click on it it turns into a checkboxâ¦ which is > WTF but it shouldn't matter atm > > 3. DynamicComposableModel holds the item in a Dictionary, since you can't > provide accessors for each item, you have to cobble together some other > selector, as shown in createWidgets > > 4. I don't know if this is the best approach, but I've been using something > like this for quite a while > > I'm quite busy this week, however I scheduled to take a look at the Spec > book next week as I should probably write something thereâ¦ > So if you have any more questions/comments please ask. > > Peter > > On Wed, May 18, 2016 at 2:19 PM, Marion Noirbent < > ms.noirbent(a)etudiant.univ-lille1.fr> wrote: > >> Ok, I wait your answer. >> Thanks for your help. >> Marion, >> >> >> Le 18/05/2016 12:04, Peter UhnÃ¡k a Ã©crit : >> >>> Yes but someone must call rebuildWidgetâ¦ I will try to take a look at this >>> today and give a better/more comprehensive example. >>> >>> Peter >>> >>> On Wed, May 18, 2016 at 1:01 PM, stepharo <stepharo(a)free.fr> wrote: >>> >>> I do not get it. >>>> >>>> I still think that the solution of peter is the one to implement >>>> >>>> rebuildWidget >>>> self widgets removeAll. >>>> self createWidgets. >>>> self needFullRebuild: false. >>>> self buildWithSpecLayout: self dynamicLayout. >>>> self alignButtons >>>> >>>> >>>> dynamicLayout >>>> | keys | >>>> keys := self widgets keys. >>>> ^ SpecLayout composed >>>> newColumn: [ :c | >>>> keys do: [ :key | c newRow: key height: self class >>>> buttonHeight ]. >>>> c newRow: [ :r | ] ]; >>>> yourself >>>> >>>> >>>> >>>> Le 18/5/16 Ã 12:46, Marion Noirbent a Ã©crit : >>>> >>>> Because I would use "openWithSpec" to build only when the widget is >>>> ready, >>>> >>>>> but it call a method (with the good pragma) on the class side. >>>>> >>>>> In the example i use i have add RadioButtonModel with addRadioButton: in >>>>> the collection buttons, it's not empty but RadioButtonModel is a >>>>> ComposableModel and layout: is define in the subclass >>>>> DynamicComposableModel . >>>>> >>>>> Le 18/05/2016 10:22, stepharo a Ã©crit : >>>>> >>>>> But why from the class side. >>>>>> >>>>>> buttons >>>>>> ^ buttons >>>>>> >>>>>> returns an empty collection >>>>>> >>>>>> and >>>>>> >>>>>> rebuildWidget >>>>>> self widgets removeAll. >>>>>> self createWidgets. >>>>>> self needFullRebuild: false. >>>>>> self buildWithSpecLayout: self dynamicLayout. >>>>>> self alignButtons >>>>>> >>>>>> >>>>>> >>>>>> Le 18/5/16 Ã 11:31, Marion Noirbent a Ã©crit : >>>>>> >>>>>> I was trying to use it but i have still the problem to call the >>>>>>> instance method from the class side, so i call the >>>>>>> buildWithSpecLayout: in the method to add buttons in the collection, >>>>>>> it seems work but i have an "MessageNotUnderstood" >>>>>>> RadioButton>>layout: >>>>>>> >>>>>>> Le 18/05/2016 09:20, stepharo a Ã©crit : >>>>>>> >>>>>>> marion the solution is what peter proposes. >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>> >>>>>>>> Le 18/5/16 Ã 11:14, Marion Noirbent a Ã©crit : >>>>>>>> >>>>>>>> In fact i was trying to modify RadioButtonGroup to turn it into a >>>>>>>>> widget, #buttons is not a widget but its collection of widget. >>>>>>>>> >>>>>>>>> May you have confused RadioButtonGroup with the MenuModel / >>>>>>>>> MenuGroupModel / MenuItemModel which are widgets. I take inspiration >>>>>>>>> from them and I would got the same kind of behaviour. >>>>>>>>> >>>>>>>>> Le 17/05/2016 21:11, stepharo a Ã©crit : >>>>>>>>> >>>>>>>>> Thanks Johan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> We looked at >>>>>>>>>> >>>>>>>>>> RadioButtonGroupExample >>>>>>>>>> >>>>>>>>>> but you see we cannot have a RadioButtonGroupPresenter having 2, 3 >>>>>>>>>> or 4 >>>>>>>>>> radioButton. >>>>>>>>>> >>>>>>>>>> Stef >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Le 17/5/16 Ã 18:52, Johan Fabry a Ã©crit : >>>>>>>>>> >>>>>>>>>> Hi Marion, >>>>>>>>>>> >>>>>>>>>>> the class side message of defaultSpec is generally meant to be >>>>>>>>>>> used if >>>>>>>>>>> you use a fixed number of widgets, so you can put the reference to >>>>>>>>>>> the >>>>>>>>>>> name of each widget there (in cour case #buttons). For variable >>>>>>>>>>> number >>>>>>>>>>> of widgets you should have a look at the dynamic features of Spec. >>>>>>>>>>> >>>>>>>>>>> That being said, It looks like what you really want to use is a >>>>>>>>>>> Radio >>>>>>>>>>> Button Group. Have a look at RadioButtonGroupExample. >>>>>>>>>>> >>>>>>>>>>> HTH >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Does this mail seem too brief? Sorry for that, I donât mean to be >>>>>>>>>>> rude! Please see http://emailcharter.org . >>>>>>>>>>> >>>>>>>>>>> Johan Fabry - http://pleiad.cl/~jfabry >>>>>>>>>>> PLEIAD and RyCh labs - Computer Science Department (DCC) - >>>>>>>>>>> University of Chile >>>>>>>>>>> >>>>>>>>>>> On May 17, 2016, at 13:48, Marion Noirbent >>>>>>>>>>> >>>>>>>>>>>> <ms.noirbent(a)etudiant.univ-lille1.fr> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> I'm trying to create a widget whith Spec, managing a collection >>>>>>>>>>>> of >>>>>>>>>>>> RadioButton. But I have a problem with defaultSpec (the accessor >>>>>>>>>>>> of >>>>>>>>>>>> the collection is the methods "buttons") : >>>>>>>>>>>> >>>>>>>>>>>> If i put defaultSpec on class side, i can't acces the collection >>>>>>>>>>>> of >>>>>>>>>>>> the instance. (the following code iterate on the string) >>>>>>>>>>>> >>>>>>>>>>>> defaultSpec >>>>>>>>>>>> <spec: #default> >>>>>>>>>>>> ^ SpecLayout composed >>>>>>>>>>>> newColumn: [ :column | #buttons do: [ :item | column >>>>>>>>>>>> add: >>>>>>>>>>>> item ] ]; >>>>>>>>>>>> yourself >>>>>>>>>>>> >>>>>>>>>>>> If i put it on instance side, the lookup don't find it (in the >>>>>>>>>>>> book >>>>>>>>>>>> Building UI with Spec, it said the lookup begin by the instance >>>>>>>>>>>> side >>>>>>>>>>>> and it allow to have specific UI, in part about layout) >>>>>>>>>>>> >>>>>>>>>>>> defaultSpec >>>>>>>>>>>> <spec: #default> >>>>>>>>>>>> ^ SpecLayout composed >>>>>>>>>>>> newColumn: [ :column | self buttons do: [ :item | column >>>>>>>>>>>> add: >>>>>>>>>>>> item ] ]; >>>>>>>>>>>> yourself >>>>>>>>>>>> >>>>>>>>>>>> Any idea ? >>>>>>>>>>>> >>>>>>>>>>>> Marion Noirbent, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> -- >> Ma clÃ© publique sur pgp.mit.edu >> >> > -- Ma clÃ© publique sur pgp.mit.edu

May 20, 2016

DSLDI'16: Call for Talk Proposals

by Tijs van der Storm

********************************************************************* CALL FOR TALK PROPOSALS DSLDI 2016 Fourth Workshop on Domain-Specific Language Design and Implementation October 31, 2016 Amsterdam, Netherlands Co-located with SPLASH http://2016.splashcon.org/track/dsldi2016 https://twitter.com/wsdsldi ********************************************************************* Deadline for talk proposals: August 1, 2016 *** Workshop Goal *** Well-designed and implemented domain-specific languages (DSLs) can achieve both usability and performance benefits over general-purpose programming languages. By raising the level of abstraction and exploiting domain knowledge, DSLs can make programming more accessible, increase programmer productivity, and support domain-specific optimizations. The goal of the DSLDI workshop is to bring together researchers and practitioners interested in discussing how DSLs should be designed, implemented, supported by tools, and applied in realistic contexts. The focus of the workshop is on all aspects of this process, from soliciting domain knowledge from experts, through the design and implementation of the language, to evaluating whether and how a DSL is successful. More generally, we are interested in continuing to build a community that can drive forward the development of modern DSLs. An additional goal of this year's workshop is to encourage discussion about the usability of DSLs, and to establish connections with researchers in related areas, such as end-user software engineering, who have studied human factors of programming languages and tools. *** Workshop Format *** DSLDI is a single-day workshop and will consist of moderated audience discussions structured around a series of talks. The role of the talks is to facilitate interesting and substantive discussion. Therefore, we welcome and encourage talks that express strong opinions, describe open problems, propose new research directions, and report on early research in progress. Proposed talks should be on topics within DSLDI's area of interest, which include but are not limited to: * solicitation and representation of domain knowledge * DSL design principles and processes * DSL implementation techniques and language workbenches * domain-specific optimizations * human factors of DSLs * tool support for DSL users * community and educational support for DSL users * applications of DSLs to existing and emerging domains * studies of usability, performance, or other benefits of DSLs * experience reports of DSLs deployed in practice *** Call for Submissions *** We solicit talk proposals in the form of short abstracts (max. 2 pages). A good talk proposal describes an interesting position, open problem, demonstration, or early achievement. The submissions will be reviewed on relevance and clarity, and used to plan the mostly interactive sessions of the workshop day. Publication of accepted abstracts and slides on the website is voluntary. * Deadline for talk proposals: August 1, 2016 * Notification: September 5, 2016 * Workshop: October 31, 2016 * Submission website: https://dsldi16.hotcrp.com/ *** Workshop Organization *** Organizers: * Eric Walkingshaw (Oregon State University) * Tijs van der Storm (CWI) Program committee: * Iman Avazpour (Deakin University) * Christopher Bogart (Carnegie Mellon University) * Andy Gill (University of Kansas) * Sylvia Grewe (TU Darmstadt) * Kate Howland (University of Sussex) * Lindsey Kuper (Intel Labs) * Darya Kurilova (Carnegie Mellon University) * Ralf LÃ¤mmel (University of Koblenz-Landau) * Tanja Mayerhofer (Vienna University of Technology) * Marjan Mernik (University of Maribor) * Sarah Mount (King's College London) * Justin Pombrio (Brown University) * Tillmann Rendel (University of TÃ¼bingen) * Tiark Rompf (Purdue & Oracle Labs) * Sonja Schimmler (Bundeswehr University Munich) * Markus VÃ¶lter (itemis) * Peng Wu (Huawei America Lab)

May 20, 2016