headers
commits | 1 Apr 2011 01:55
Favicon

Daily Commit Log

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours:

http://lists.squeakfoundation.org/pipermail/packages/2011-March/004469.html

Name: Protocols-nice.35
Ancestors: Protocols-ul.34

Remove FakeClassPool reference because I don't like it.

=============================================
Permalink | Reply | 0 comments |
headers
commits | 1 Apr 2011 02:00
Favicon

The Trunk: Tools-eem.304.mcz

Eliot Miranda uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-eem.304.mcz

==================== Summary ====================

Name: Tools-eem.304
Author: eem
Time: 31 March 2011, 6:29:51.619 pm
UUID: bf2886ee-1f33-47ad-9025-c7253c619dd8
Ancestors: Tools-nice.303

Debugger:
	- use the selectedContext's method when browsing
	  senders and implementors.
	- do not discard changes if the compilation of an edited
	  method fails when in a block.

=============== Diff against Tools-nice.303 ===============

Item was changed:
  ----- Method: Debugger>>browseMessages (in category 'context stack menu') -----
  browseMessages
  	"Present a menu of all messages sent by the currently selected message.
  	Open a message set browser of all implementors of the message chosen.
  	Do nothing if no message is chosen."

  	contextStackIndex = 0 ifTrue: [^ self].
+ 	self withSelectorAndMessagesIn: self selectedContext method
- 	self withSelectorAndMessagesIn: currentCompiledMethod
  		evaluate: [:selector| self systemNavigation browseAllImplementorsOf: selector]!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eliot Miranda | 1 Apr 2011 03:48
Picon

inlining repeat and the decompiler (Compiler-nice.186)

Hi All,


    just a note that once Compiler-nice.186 is installed, which inlines #repeat, one needs to recompile all senders of repeat to avoid having the decompiler crap out on you, e.g. in the debugger.  For example the compilation of

GeneratorTest methods for generators
fibonacciSequence
"Yields an infinite sequence of fibonacci numbers."
^ Generator on: [ :generator |
| a b |
a := 0. b := 1.
[ a := b + (b := a).
 generator yield: a ]
repeat ]

with non-inlined repeat:
pushLit: Generator
closureNumCopied: 0 numArgs: 1 bytes 34 to 72
pushConstant: nil
push: (Array new: 2)
popIntoTemp: 1
pushConstant: 0
popIntoTemp: 0 inVectorAt: 1
pushConstant: 1
popIntoTemp: 1 inVectorAt: 1
pushTemp: 0
pushTemp: 1
closureNumCopied: 2 numArgs: 0 bytes 52 to 70
pushTemp: 1 inVectorAt: 1
pushTemp: 0 inVectorAt: 1
storeIntoTemp: 1 inVectorAt: 1
send: #+ (1 arg)
popIntoTemp: 0 inVectorAt: 1
pushTemp: 0
pushTemp: 0 inVectorAt: 1
send: #yield: (1 arg)
blockReturn
send: #repeat (0 args)
blockReturn
send: #on: (1 arg)
returnTop

with inlined repeat:
pushLit: Generator
closureNumCopied: 0 numArgs: 1 bytes 34 to 53
pushConstant: nil
pushConstant: nil
pushConstant: 0
popIntoTemp: 1
pushConstant: 1
popIntoTemp: 2
L1:
pushTemp: 2
pushTemp: 1
storeIntoTemp: 2
send: #+ (1 arg)
popIntoTemp: 1
pushTemp: 0
pushTemp: 1
send: #yield: (1 arg)
pop
jumpTo: L1
pushConstant: nil
blockReturn
send: #on: (1 arg)
returnTop


will cause the decompiler to fail horribly if the non-inlined result is decompiled with Compiler-nice.186 installed.  The fix is merely to recompile it (and other senders of #repeat).  The underlying problem is that if the is given temp names via a schematicTempNamesString then that string must match the temps in the method, and in the above if repeat is not inlined a and b are remote, and hence the schematicTempNamesString is [generator (a b)] but if repeat is inlined then they are local and the schematicTempNamesString is [generator a b].

BTW, kudos to Nicholas for the newParser/newCompiler changes!

best
Eliot
Permalink | Reply | 6 comments |
headers
Denis Kudriashov | 1 Apr 2011 08:43
Picon

Re: Progress bar design pattern

Hello
 
I like the "meta approach"... but it doesn't look easy to implement for me!
Have you seen something like that implemented? or some paper written?

No. I dont see something similar. But I know that it is possible to inspect full contexts chain of any process. So I think analizing of process execution can be done
Permalink | Reply | 0 comments |
headers
Bert Freudenberg | 1 Apr 2011 10:29
Picon
Gravatar

Re: SimpleMorphic Editors

On 31.03.2011, at 21:15, David T. Lewis wrote:

> On Thu, Mar 31, 2011 at 08:00:08PM +0200, Bal?zs K?si wrote:
>> On Thu, Mar 31, 2011 at 7:46 PM, Casey Ransberger
>> <casey.obrien.r <at> gmail.com> wrote:
>>> I'd like to reverse this statement. In the longer term I'd like to see
>>> SimpleMorphic into the core system, and get LegacyMorphic or BigMorphic
>>> or whatever we'd call it out of the core and into Squeaksource.
>> 
>> I think we could do even better: Make all the ui frameworks loadable
>> and unloadable, and make it easy to implement your own.
>> 
>> Bal?zs
> 
> Yes!
> 
> Dave

Not quite a plan yet, but great idea!

The old FullMorphic could be maintained as part of Etoys.

- Bert -
Permalink | Reply | 16 comments |
headers
Denis Kudriashov | 1 Apr 2011 10:33
Picon

Re: Progress bar design pattern


2011/4/1 Yoshiki Ohshima <yoshiki <at> vpri.org>
 I don't understand the problem.  Let us say we start from the
example in the method:

--------------------
'Now here''s some Real Progress'
       displayProgressAt: Sensor cursorPoint
       from: 0 to: 10
       during: [:bar |
       1 to: 10 do: [:x | bar value: x.
                       (Delay forMilliseconds: 500) wait]].
--------------------

and your "algorithm" here would be:

       1 to: 10 do: [:x | "do something here"
                       (Delay forMilliseconds: 500) wait].

It is already reasonably decoupled to me, but I take that you want to
keep the "algorithm" really prestine and don't want to have "bar
value: x" call in there, and completely get rid of anything from "do
something here".  Is this the case?

 There still have to have some way to tell how much percent of work
done from the "algorithm" to the progress notification mechanism.  In
the possible meta approach (which would not be that hard at all), I'd
make an instance variable for the object that represents your
algorithm state, and the algorithm assigns a value to the instance
variable, and the progress bar displayer that is running in a separate
thread looks at the variable periodically and update the screen.

You dont really need to convert some temp to instance variables. You can track some current context temp variable value (context of concrete process which executes algorithm).
So you need meta description to specify what peace of code in process context provide progress information

  Note that your algorithm may not be a loop.  It is totally legitimate
to write:

algorithm
       self doA.
       bar value: 0.33.
       self doB.
       bar value: 0.66.
       self doC.

where doA, doB, doC are long running computation.  So, really generic
way to view the progress of something from outside without the
knowledge of where to look at and how to interpret these values are
not going to fly.

It's not problem. We have algorithm:

MyClass>>algorithm
       self doA.
       self doB.
       self doC.

And with meta description we can write like:

Progress for: MyClass>>algorithm when: [:desc |
    desc for: MyClass>>doB value: 0.33.
   desc for: MyClass>>doC value: 0.66
]

And doA/B/C can doing some inner loops which we can track with extra meta descriptions.
Permalink | Reply | 2 comments |
headers
Theo D'Hondt | 1 Apr 2011 11:47
Picon
Favicon

Dynamic Languages Symposium 2011: call for participation

Dynamic Languages Symposium 2011  

Co-located with SPLASH 2011
In association with ACM SIGPLAN

Portland, Oregon, USA, October 24, 2011

http://www.dynamic-languages-symposium.org/dls-11/

*** Call for papers ***

The 7th Dynamic Languages Symposium (DLS) at SPLASH 2011 is a forum for discussion of dynamic languages, their implementation and application. While mature dynamic languages including Smalltalk, Lisp, Scheme, Self, Prolog, and APL continue to grow and inspire new converts, a new generation of dynamic scripting languages such as Python, Ruby, PHP, Tcl, Lua, and JavaScript are successful in a wide range of applications. DLS provides a place for researchers and practitioners to come together and share their knowledge, experience, and ideas for future research and development.

DLS 2011 invites high quality papers reporting original research, innovative contributions or experience related to dynamic languages, their implementation and application. Accepted Papers will be published in the ACM Digital Library.

Areas of interest include but are not limited to:

- Innovative language features and implementation techniques
- Development and platform support, tools
- Interesting applications
- Domain-oriented programming
- Very late binding, dynamic composition, and runtime adaptation
- Reflection and meta-programming
- Software evolution
- Language symbiosis and multi-paradigm languages
- Dynamic optimization
- Hardware support
- Experience reports and case studies
- Educational approaches and perspectives
- Object-oriented, aspect-oriented, and context-oriented programming

* Submissions and proceedings *

We invite original contributions that neither have been published previously nor are under review by other refereed events or publications. Research papers should describe work that advances the current state of the art. Experience papers should be of broad interest and should describe insights gained from substantive practical applications. The program committee will evaluate each contributed paper based on its relevance, significance, clarity, and originality.

Accepted papers will be published in the ACM Digital Library.

Papers are to be submitted electronically at http://www.easychair.org/conferences?conf=dls2011 in PDF format. Submissions must not exceed 12 pages and need to use the ACM format, templates for which can be found at http://www.acm.org/sigs/pubs/proceed/template.html.

* Important dates *

Submission of papers: June 17, 2011 (hard deadline)
Author notification: July 19, 2011
Final versions due: August 19, 2011
DLS 2011: October 24, 2011
SPLASH 2011: October 22-27, 2011

* Program chair *

Theo D'Hondt, Software Languages Lab, Vrije Universiteit Brussel, Belgium

* Program committee *

Andrew Black, Portland State University, USA
William R. Cook, University of Texas at Austin, USA
Marc Feeley, University of Montreal, Canada
Roberto Ierusalimschy, PUC-Rio, Brazil
Michele Lanza, University of Lugano, Switzerland
Hidehiko Masuhara, University of Tokyo, Japan
Mira Mezini, University of Darmstadt, Germany
Mark Miller, Google, USA
Manuel Serrano, INRIA Nice, France
Laurence Tratt, Middlesex University, UK
David Ungar, IBM, USA
Didier Verna, EPITA Research and Development Laboratory, France

________________
Theo D'Hondt
tjdhondt <at> vub.ac.be
Permalink | Reply | 0 comments |
headers
Edgar J. De Cleene | 1 Apr 2011 12:08
Picon

Re: SimpleMorphic Editors


On 3/31/11 2:46 PM, "Casey Ransberger" <casey.obrien.r <at> gmail.com> wrote:

> I'd like to reverse this statement. In the longer term I'd like to see
> SimpleMorphic into the core system, and get LegacyMorphic or BigMorphic or
> whatever we'd call it out of the core and into Squeaksource.
+1
This is my view also.
I push the idea of unloadable / loadable packages in 3.10.

Once we have SimpeMorphic working not only like in Cuis , also all tools
like PackageBrowser, MonticelloBrowser, etc, we could unload LegacyMorphic
(like this name)

And learn enough for my proposal of Traslator package, something taking
LegacyMorphic and convert to SimpleMorphic.

Edgar
Permalink | Reply | 1 comment |
headers
Hannes Hirzel | 1 Apr 2011 12:12
Picon

Re: SimpleMorphic Editors

On 4/1/11, Edgar J. De Cleene <edgardec2005 <at> gmail.com> wrote:
>
>
>
> On 3/31/11 2:46 PM, "Casey Ransberger" <casey.obrien.r <at> gmail.com> wrote:
>
>> I'd like to reverse this statement. In the longer term I'd like to see
>> SimpleMorphic into the core system, and get LegacyMorphic or BigMorphic or
>> whatever we'd call it out of the core and into Squeaksource.
> +1
> This is my view also.
+1

--Hannes
Permalink | Reply | 0 comments |
headers
Hannes Hirzel | 1 Apr 2011 12:17
Picon

Re: Ometa vs XTreams PEG, PetitParser, Helvetia

At this very moment I think we just need to make sure we can load
OMeta and XTreams into the release 4.2 and the ongoing development
trunk version so that people can compare and get a better idea.

1)
Randal, in January I loaded XTreams into the current version at that
time. You recently did as well a trial load, what is the script to
load it?

2)
Regarding OMeta, I did a load I think last October --- what do I need
to do as of now to load it?

3)
Does somebody more closely follow the development of PetitParser and
Helvetia on the Pharo side and could give a short report on what is
happening there? (Or just some pointers to helpful Pharo list mails)

--Hannes

On 3/31/11, Randal L. Schwartz <merlyn <at> stonehenge.com> wrote:
>>>>>> "Casey" == Casey Ransberger <casey.obrien.r <at> gmail.com> writes:
>
> Casey> OMeta is ridiculously cool. You can do source to source
> Casey> translation in some cases, for example, without a pretty printer
> Casey> by running your grammar transformations through backward. I'm not
> Casey> aware of any other system that let's you do that.
>
> Except maybe XTreams PEG. :)
>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
> <merlyn <at> stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
> See http://methodsandmessages.posterous.com/ for Smalltalk discussion
>
>
Permalink | Reply | 3 comments |

Gmane