headers
K. K. Subramaniam | 1 May 03:29
Picon

Re: Starting Smalltalk with Squeak problem with color selector

On Wednesday 29 April 2009 4:05:12 pm Tom18 wrote:
> I am starting programming in smalltalk and I would like to create a morph
> in which I would like to insert a color selector that changes the color of
> my morph.
From an inspector of that morph, type
	self changeColor
and doIt to get a color selector will popup to change the color of a morph. 
You can add a small button to the morph that sends this message when clicked. 
The senders of this method has many examples of usage.

HTH .. Subbu
Permalink | Reply | 0 comments |
headers
Michael van der Gulik | 1 May 05:13
Picon

Modifying classes (was: Multi-core VMs)

On 5/1/09, Michael van der Gulik <mikevdg <at> gmail.com> wrote:
> (regarding hypothetical implementation of a multi-core capable Squeak VM)
>
> On 4/30/09, Nicolas Cellier <nicolas.cellier.aka.nice <at> gmail.com> wrote:
>> 2009/4/30 Michael van der Gulik <mikevdg <at> gmail.com>:
>
>>> *Most* parts of the VM will continue working fine. The parts that will
>>> break... er... some of the parts that will break are:
>>>
>>> * garbage collection.
>>> * allocating memory for new objects.
>>> * primitives and devices.
>>> * pointer swapping *might* need to be atomic (become:, becomeForward:).
>>> * Semaphore signalling.
>>> * (more things???)
>>>
>>
>> I love the *might*
>>
>> What happens for example if you change a class definition... Say add
>> or remove an instance slot.
>> What would happen if the becomeForward on the array of instances and
>> subinstances and method dictionaries were not atomic?
>
> Umm... brain cogs turning... umm...
>
> To retain the behaviour that Squeak has now, the safest, least buggy
> and easiest way is to do the above operation with a lock on the entire
> VM. Currently this is done in ClassBuilder>>update:to: by using
> BlockContext>>valueUnpreemptively. Whole VM locks suck, but nobody has
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andreas Raab | 1 May 06:13
Picon
Picon

Re: [ANN] A new scheduler + VM changes alpha-release

Igor Stasenko wrote:
> I have built a new VM with closure support (VMMaker.dtl.120).
> A changeset can be loaded to VMMaker w/o changes, except changing the
> Interpreter class redefinition.
> All is needed is to add 3 class vars to Interpreter manually:
> ProcessActionIndex InterruptedProcessIndex InterruptProcessIndex

Hm ... I compiled a VM with your changes but I can't recreate your 
results. My results are more in the range of 15:1 to 20:1 in a 
before-after comparison. Are you using the code from 
http://bugs.squeak.org/view.php?id=7345 or something more elaborate by now?

Cheers,
   - Andreas
Permalink | Reply | 1 comment |
headers
Igor Stasenko | 1 May 11:14
Picon

Setting a preempted process priority glitch

Here the test, showing that setting a priority of preempted process
may not result of what you expected:

| first p1 p2 |
first := nil.
p1 := [ first ifNil: [ first:= 1] ] forkAt: Processor activePriority - 1.
p2 := [ first ifNil: [ first:= 2] ] forkAt: Processor activePriority - 2.
p1 priority: 10.
(Delay forMilliseconds: 100) wait.
first

at first, an order in which processes should awake is p1 then p2.
But then, if we setting p1 priority lower than p2 , the order should
be p2 then p1.

To fix this we should reschedule preempted process:

Process>>priority: anInteger
(anInteger >= Processor lowestPriority and:[anInteger <= Processor
highestPriority])
	ifTrue: [priority := anInteger]
	ifFalse: [self error: 'Invalid priority: ', anInteger printString]
(myList isNil or: [myList class == Semaphore]) ifTrue: [ ^ self  ].
"we are preempted. reschedule at new priority"
self suspend;resume.

This issue shows, that comment in Process>>#terminate, lying to us:

"Since the receiver is not the active process, drop its priority to
rock-bottom so that
(Continue reading)

Permalink | Reply | 8 comments |
headers
Bert Freudenberg | 1 May 11:22
Picon
Gravatar

Re: Re: FFI question [WAS] squeakopendbx, which VM?


On 30.04.2009, at 23:55, Andreas Raab wrote:

> Bert Freudenberg wrote:
>> On 30.04.2009, at 23:22, Mariano Martinez Peck wrote:
>>>    However, you can of course manually do the "linking" step - in  
>>> the
>>>    ffi function declarations, use "libopendbx.so.1" as module  
>>> instead
>>>    of just "opendbx". This will then only work on Linux of course,
>>>    since other Unix platforms use different schemes of versioning
>>>    libraries.
>>>
>>>
>>> Indeed. That's why I don't want to change the module name.
>> Well, you can also automate this "pseudo-linking". When starting  
>> up, just patch the right module name for the current platform into  
>> all the FFI declarations. That's how the OpenGL FFI bindings in  
>> Croquet work ...
>
> The way this is done is purely for historical reasons (and an  
> *extremely* bad example that should not be taught to anyone). The  
> Right Way to do this is to have a subclass of ExternalLibrary and  
> implement the class-side method #moduleName along the lines of:
>
> MyLibrary class>>moduleName
>  "Answer the module name to use for this library"
>  Smalltalk platformName = 'Win32' ifTrue:[^'MyLibrary32.dll'].
>  Smalltalk platformName = 'unix' ifTrue:[
>     "check various locations and versions"
(Continue reading)

Permalink | Reply | 5 comments |
headers
Tom18 | 1 May 04:32
Picon

Re: Starting Smalltalk with Squeak problem with color selector


Thanks to you all for your help. I will try  what you have told me ;)

Tom18 wrote:
> 
> Hello all,
> 
> I am starting programming in smalltalk and I would like to create a morph
> in which I would like to insert a color selector that changes the color of
> my morph.
> Maybe it is easy to do but I have tried many times without success. 
> 
> Thanks for the future responses.
> 

--

-- 
View this message in context: http://www.nabble.com/Starting-Smalltalk-with-Squeak-problem-with-color-selector-tp23294667p23327653.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.
Permalink | Reply | 0 comments |
headers
Bert Freudenberg | 1 May 11:40
Picon
Gravatar

Re: [RFI] A way to browse code saved with a *.pr project.


On 01.05.2009, at 00:32, Jerome Peace wrote:

>
> Hi all,
>
> Problem: You develop an application in a project under one set of  
> circumstances.
> Save the project out to disk.
> Them want to load it back in another entirely different set of  
> circumstances.
>
> Some Browser or morph or something saved with the project doesn't  
> want to load back in.*
>
>
> The story I would like to see implemented is:
>
> In addition to the option of loading the project
> 1) can I opt instead to load just the code associated with the  
> project into a code browser. And/Or
> 2) save the code associated with the project as a fileout to the  
> disk w/o loading the project at all.
>
> (Then filelist would allow the many things it knows to do with filed  
> out code.)
>
> This story is strictly for .pr files. I know to generally save out a  
> projects change set first before saving a project. I am looking for  
> a way to ease things, particularly when I forget the extra steps.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Igor Stasenko | 1 May 11:57
Picon

Improving a Process termination procedure

There are a potential of having incorrect behavior , when terminating
a preempted or waiting process:

with introduction of ProcessLocalVariable, it is essential that
context unwinding procedure should be performed only
for currently active process.

Here the proposal how to ensure this:

if terminating process is not active process we should do the following:

suspendedContext := proc suspendedContext.
currentProces := Processor activeProcess.
proc suspendedContext:  [  Processor activeProcess
terminateFromContext: suspendedContext. Processor switchToProcess:
currentProcess ] asContext.
Processor switchToProcess: proc.

here #switchToProcess: is explicit switch (bypassing scheduling logic).

If we don't care about immediate termination of process and getting
back to process who initiated termination as soon as possible, then
simply do:
process terminateSoon.

which can be implemented as:

Process>>terminateSoon
| termContext |
termContext := suspendedContext.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Igor Stasenko | 1 May 12:11
Picon

Re: Improving a Process termination procedure

Another improvement would be to marry the process termination with
exception handling,
and nicely signal ProcessTerminatedException.
This offers many practical benefits, since then we could write:

[ ... ] on: ProcessTerminatedException do: [:ex |
   "oh man we're been terminated"
].

But i'm not expert in exception handling.
Can someone give me a sample, how to signal such exception in potential
#terminateFromContext: method?

2009/5/1 Igor Stasenko <siguctua <at> gmail.com>:
> There are a potential of having incorrect behavior , when terminating
> a preempted or waiting process:
>
> with introduction of ProcessLocalVariable, it is essential that
> context unwinding procedure should be performed only
> for currently active process.
>
> Here the proposal how to ensure this:
>
> if terminating process is not active process we should do the following:
>
> suspendedContext := proc suspendedContext.
> currentProces := Processor activeProcess.
> proc suspendedContext:  [  Processor activeProcess
> terminateFromContext: suspendedContext. Processor switchToProcess:
> currentProcess ] asContext.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Igor Stasenko | 1 May 12:29
Picon

Re: Re: [ANN] A new scheduler + VM changes alpha-release

2009/5/1 Andreas Raab <andreas.raab <at> gmx.de>:
> Igor Stasenko wrote:
>>
>> I have built a new VM with closure support (VMMaker.dtl.120).
>> A changeset can be loaded to VMMaker w/o changes, except changing the
>> Interpreter class redefinition.
>> All is needed is to add 3 class vars to Interpreter manually:
>> ProcessActionIndex InterruptedProcessIndex InterruptProcessIndex
>
> Hm ... I compiled a VM with your changes but I can't recreate your results.
> My results are more in the range of 15:1 to 20:1 in a before-after
> comparison. Are you using the code from
> http://bugs.squeak.org/view.php?id=7345 or something more elaborate by now?
>
Well, i made some shortcuts, like removing fallback handler and it
improved a bit.
I checked everything thoughoutly, and since performance degrades
linearly with each introduced message send,
i don't think its because of bogus code.
The overhead is because we using interpreter to switch processes:
 -removing process from a list
 - adding process to a list
etc etc.

Of course, i could make an additional prims to speed things up for a
little, like doing
  LinkedList>>removeFirst:
  LinkedList>>addLast:
primitively.
But i wouldn't care about it now. I want to explore the real benefits
(Continue reading)

Permalink | Reply | 0 comments |

Gmane