[Pharo-users] DSLDI'16: Call for Talk Proposals

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

Re: [Pharo-users] Spec layout

[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.noirb...@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  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
>>> numb

[Pharo-users] Why is split: implemented in the separator rather than the string?

[Andy Burnett]

>
>
>
> Message: 1
> Date: Thu, 19 May 2016 20:18:09 -0700
> From: John Pfersich 
> To: Any question about pharo is welcome 
> Subject: Re: [Pharo-users] Why is split: implemented in the separator
> rather  than the string?
> Message-ID: 
> 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

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

[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

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

[Holger Freyther]

> On 19 May 2016, at 10:40, Sven Van Caekenberghe  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...

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

[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-tp4895729p4896436.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

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

[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.l...@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
>
>

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

[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 
) 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 
mailto:offray.l...@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

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

[stepharo]

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