Nicolai Hess | 25 Nov 23:39 2014
Picon

Re: Athens Repository (NativeBoost)



2014-11-24 23:34 GMT+01:00 Esteban Lorenzano <estebanlm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
both are integrated into the image. 
while NB has been maintained directly, athens should still be loadable (if not the case… we have a problem for the future :P).

what does that mean for athens, yes unload and loadable from the image or loadable from the sthub repository?

 

yes, we are slowly moving in the opposite direction of “all maintained in the image”, and eventually we plan/dream to have a small kernel and a bunch of configurations to produce Pharo. 

now, about NB, we do not have special plans. 
it is in the image and it will be maintained as part of Pharo. 

now, since the most common use of NB is for FFI, and NB is not present in all platforms, we are working (Ronie, in this case) in a “unified FFI”, which will provide a common abstraction layer for several FFI frameworks (NB, OldFFI, Alien…). With that, we can choose which one of the frameworks we use depending on the situation (but ideally, we will maintain just one, the one that fits better in Pharo). 
Again… this are just ideas for the future :)

Esteban



On 24 Nov 2014, at 23:23, Nicolai Hess <nicolaihess-S0/GAf8tV78@public.gmane.org> wrote:

2014-11-24 20:41 GMT+01:00 Torsten Bergmann <astares-Mmb7MZpHnFY@public.gmane.org>:
Hi,

were is NB currently maintained? Only within the image as it is integrated
or still with an external config and on STHub?

The reason why I ask: when I load the latest NB-Core package
from STHub it looks like this one is outdated and back from Pharo3 day
(trying to load it gives problems from changes in Pharo 4).

So it looks like NB was originally developed external using STHub, then integrated
into standard image and now it is only internally in-image managed. OK.

But the future goal is as far as I understood to manage more and
more packages using external configs again.

What is the status and future plan for NB? Will the repo get
synchronized? Or will it stay internal only?

Thx
T.


I was about to ask the same question for Athens, the packages in pharo4 and sthub diverge.
I can merge the sthub and pharo4 version for Athens (and mabe NB), I just don't know what
is the plan for the feauture, manage packages for Athens and NB in the image or on sthub.



Picon

Dependencies Analyzer

I installed it in my 3.0 but it crashes with a DNU on  TreeNodeModel>>position: 

I loaded it like this:

Gofer it
smalltalkhubUser: 'BaptisteQuide' project: 'PackageDependenciesAnalysis';
configuration;
loadStable 

The article on 


says that it loads on 3.0 but well, it doesn't say it works there.

Looks like widgets have had a facelift.

What was changed there?

It is an interesting tool for my own work too, so I'd like to have it running.

Any pointers before digging down the rabbit hole?

Phil


Christophe Demarey | 25 Nov 09:32 2014
Picon
Picon

Fwd: [ci-announces] Storage maintenance planned tomorrow (2014/11/25)

Hello,

Pleas find below an announce of a maintenance on the Inria CI infrastructure.
It means we will have to shutdown our slaves this afternoon and no CI job run will be available before tomorrow.

Regards,
Christophe.

Début du message réexpédié :

Date : 24 novembre 2014 09:47:56 HNEC
Objet : [ci-announces] Storage maintenance planned tomorrow (2014/11/25)
Répondre à : Emmanuel Jeanvoine <emmanuel.jeanvoine-MZpvjPyXg2s@public.gmane.org>

Dear users,

A maintenance of the storage infrastructure is planned on 2014/11/25 from
5pm to 11pm. In order to avoid issues, you are strongly encouraged to shut
down the virtual machines of your project before 5pm.
After that, the remaining virtual machines will be shut down by the IT
team.

If you are interested in following this maintenance you can have a look
there: https://wiki.inria.fr/ciportal/Event_20141125_storage

Thank you for your understanding,
Emmanuel

--
Emmanuel Jeanvoine                        Research Engineer
Inria Nancy - Grand Est                         Office B118
http://www.inria.fr/nancy             Tel +33 3 54 95 86 21

Attachment (smime.p7s): application/pkcs7-signature, 5812 bytes
olivier auverlot | 25 Nov 09:01 2014
Picon

Voyage,Mongo and Seaside...

Where must i initialize a mongo connection in a Seaside application when I use Voyage ?

My application use the singleton mode of Voyage.  What is the good place to create the singleton ?
  * in the initialize class method of mySeaside root WAComponent (It will called one time when Seaside initialize the hosted applications) 
  * in the instance method initialize of my Seaside root WAComponent (It will called each time that's a user start to use the application)

The second case seems to be better because the connection time is probably limited by Mongo or the connection could be broken. 

Someone have experimented good practices at this problematic ?

Best regards
Olivier ;-)
stepharo | 25 Nov 08:01 2014
Picon

callback explanation


Begin forwarded message:

From: Eliot Miranda <eliot.miranda@...>
Subject: Re: [Vm-dev] FFI callbacks
Date: 25 Nov 2014 03:19:49 GMT+1
To: Squeak Virtual Machine Development Discussion 
<vm-dev@...>
Reply-To: Squeak Virtual Machine Development Discussion 
<vm-dev@...>

Hi Bert,

On Mon, Nov 24, 2014 at 2:49 PM, Bert Freudenberg <bert@...> 
wrote:

How do they actually work? I want to know what information the thunk 
needs, and what happens when it is activated. I think SqueakJS would 
benefit from callback support.

I'll try and write this up properly in a blog post tomorrow.  But...

Callback is a wrapper round a piece of executable code, a block, and a 
"signature" (see below).  The executable code is wrapped by an 
FFICallbackThunk, an Alien, which is just a pointer to this code. Th 
code is allocated from a special pool of memory marked as executable.  
The address of the code is unique and is hence used as a key to identify 
the Callback and hence locate the block from the thunk.  The FFI 
marshalling code should pass the address of the thunk when passing the 
Callback.  Right now that has to be done explicitly.  The thunk, when 
called, invokes thunkEntry, which is defined in e.g. 
platforms/Cross/plugins/IA32ABI/ia32abicc.c (it needs a different 
definition for each API).  On x86 thinkEntry needs only to be invoked 
with the think and the stack pointer, since on x86 all arguments are 
accessible from the stack.  On other platforms thunkEntry will need to 
be invoked with the register arguments.

thunkEntry's job is to store the state necessary to return from the 
callback in an instance of either VMCallbackContext32 or 
VMCallbackContext64.  These are aliens for the following structure:

typedef struct {
     void *thunkp;
     char *stackptr;
     long *intRegArgs;
     double *floatRegArgs;
     void *savedCStackPointer;
     void *savedCFramePointer;
     union {
                             long vallong;
                             struct { int low, high; } valleint64;
                             struct { int high, low; } valbeint64;
                             double valflt64;
                             struct { void *addr; long size; } valstruct;
                         }   rvs;
     jmp_buf trampoline;
  } VMCallbackContext;

The structure lives in the stack frame of thunkEntry, hence one per 
callback.

It does three things:

1. it identifies all the input arguments.  These are accessible, 
depending on platform, through stackptr, intRegArgs and floatRegArgs.
2. it maintains the jmp_buf which can be used to longjmp back to the 
callback to return from it.
3. it has slots to hold the result to be returned from the callback (the 
union rvs).  The argument to the longjmp (the value returned from the 
setjmp in thinkEntry) tells thunkEntry how to return the result, i.e. as 
a 32-bit value, a 64-bit value, a double or a struct.

Once thinkEntry has packed up the state in its local VMCallbackContext, 
it uses

     if ((flags = interpreterProxy->ownVM(0)) < 0) {
         fprintf(stderr,"Warning; callback failed to own the VM\n");
         return -1;
     }

to "own" the VM.  If the VM is single-threaded then this can check that 
the callback is being made on the same thread as the VM, and fail 
otherwise.  If the VM is multi-threaded ownVM can block until the thread 
can enter the VM.

It then calls-back into the VM using

         interpreterProxy->sendInvokeCallbackContext(&vmcc);

which sends the message (found in the specialObjectsArray) 
#invokeCallbackContext: which is understood by Alien (see Alien 
class>>#invokeCallbackContext:).  This method wraps up the input 
argument (the raw address of thunkEntry's VMCallbackContext) in the 
relevant Alien and invokes Callback's entry point:

invokeCallbackContext: vmCallbackContextAddress "<Integer>" 
"^<FFICallbackReturnValue>"
     "The low-level entry-point for callbacks sent from the VM/IA32ABI 
plugin.
      Return via primReturnFromContext:through:.  thisContext's sender 
is the
      call-out context."
     | callbackAlien type |
     callbackAlien := (Smalltalk wordSize = 4
                         ifTrue: [VMCallbackContext32]
                         ifFalse: [VMCallbackContext64])
                             atAddress: vmCallbackContextAddress.
     [type := Callback evaluateCallbackForContext: callbackAlien]
         ifCurtailed: [self error: 'attempt to non-local return across a 
callback'].
     type ifNil:
         [type := 1. callbackAlien wordResult: -1].
     callbackAlien primReturnAs: type fromContext: thisContext

The sendInvokeCallbackContext machinery just constructs an activation of 
invokeCallbackContext: on top of the current process's stack, which is 
usually the process that called out through the FFI.  Bit it doesn't 
have to be.  threaded callbacks are too detailed for this brief message.

Callback then locates the relevant marshalling method for the callback's 
signature (actually it does this when the Callback is created, but the 
effect is the same).  Callback uses methods that identify themselves via 
pragmas to choose the relevant marshaller. e.g. for a qsort sort 
function callback the marshaller on x86 is

Callback methods for signatures
voidstarvoidstarRetint: callbackContext sp: spAlien
     <signature: #(int (*)(const void *, const void *)) abi: 'IA32'>
     ^callbackContext wordResult:
         (block
             value: (Alien forPointer: (spAlien unsignedLongAt: 1))
             value: (Alien forPointer: (spAlien unsignedLongAt: 5)))

So it fetches the arguments from the stack using Alien accessors, 
evaluates the block with them and then assigns the result via 
wordResult, and answers the type code back to invokeCallbackContext:, e.g.

VMCallbackContext32 methods for accessing
wordResult: anInteger
     "Accept any value in the -2^31 to 2^32-1 range."
     anInteger >= 0
         ifTrue: [self unsignedLongAt: 25 put: anInteger]
         ifFalse: [self signedLongAt: 25 put: anInteger].
     ^1

Then invokeCallbackContext: invokes the primitive to longjmp back to 
thunkEntry, supplying the return code that will allow thunkEntry to 
return the reslt correctly:

VMCallbackContext32 methods for primitives
primReturnAs: typeCode "<SmallInteger>" fromContext: context 
"<MethodContext>"
     <primitive: 'primReturnAsFromContextThrough' module: 'IA32ABI' 
error: ec>
     ^self primitiveFailed

Then thunkEntry switches on the return code and returns to the caller.

Note that sendInvokeCallbackContext and primReturnAsFromContextThrough 
conspire to save, set and restore the VM's notion of what the C stack is 
in the VMCallbackContext's savedCStackPointer & savedCFramePointer, 
growing the stack on callback, and cutting it back on return.  There's a 
variable in the VM, previousCallbackContext, that 
primReturnAsFromContextThrough uses to make sure returns are LIFO.

I imagine that somehow the VM's state needs to be saved, then the 
context that defined the block is activated, and then the VM would run 
the block until it returns (or until the return prim is called?), then 
the VM's state would need to be restored to what it was, and the result 
is passed back by the thunk returning.

That's right.

Am I close? Since the callback can happen at any time, and it could do 
anything, saving the whole VM state seems daunting.

Provided that the callback occurs from the context of a callout there 
are no problems.  Threaded callbacks take some more doing. Basically the 
VM needs to b sharable between threads.  This is the threaded VM 
prototype.  If you absolutely need threaded callbacks we should have a 
serious talk.  This is not trivial to productise.

HTH
--

-- 
best,
Eliot

Hilaire | 24 Nov 21:50 2014
Picon

Mess in Theme hierarchy again

It just appear the Theme hierarchy is mess again, with what look like
basic functionality methods appearing down in the hierarchy!
Result: switching between theme makes text color unreadable.

https://pharo.fogbugz.com/f/cases/14524/WateryTheme-broken-again

--

-- 
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu

Hilaire | 24 Nov 21:29 2014
Picon

What is the limit

Pharo 1.4 image = 15MB
Pharo 3 image = 22MB
Pharo4 image = 32MB

Don't know about Pharo 2.0 as, skip it.

Is there a limit?

Hopefully I gave up on the idea of tablet use but aren't we loosing the
sight on small is beautiful?

Hilaire

--

-- 
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu

Torsten Bergmann | 24 Nov 20:41 2014
Picon
Picon

NativeBoost

Hi,

were is NB currently maintained? Only within the image as it is integrated 
or still with an external config and on STHub?

The reason why I ask: when I load the latest NB-Core package
from STHub it looks like this one is outdated and back from Pharo3 day
(trying to load it gives problems from changes in Pharo 4).

So it looks like NB was originally developed external using STHub, then integrated 
into standard image and now it is only internally in-image managed. OK.

But the future goal is as far as I understood to manage more and
more packages using external configs again.

What is the status and future plan for NB? Will the repo get
synchronized? Or will it stay internal only?

Thx
T.

kilon alios | 24 Nov 19:51 2014
Picon

Pharo is mine

>> I'm certainly a good example of that. My Pharo is mine! (and I have an IDE I like which is truly 
>> mine :P)

>> And I can only encourage you to do the same ;)

what you mean ? you have customised pharo for your needs ? care to share , I am very interested :)
GitHub | 24 Nov 17:11 2014

[pharo-project/pharo-core] 27151e: 40384

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 27151ed904db256d72e83d85722db500969b23b9
      https://github.com/pharo-project/pharo-core/commit/27151ed904db256d72e83d85722db500969b23b9
  Author: Jenkins Build Server <board@...>
  Date:   2014-11-24 (Mon, 24 Nov 2014)

  Changed paths:
    A Kernel.package/SmallInteger.class/class/class initialization/initialize.st
    A Kernel.package/SmallInteger.class/class/class initialization/startUp_.st
    M Kernel.package/SmallInteger.class/class/constants/maxVal.st
    M Kernel.package/SmallInteger.class/class/constants/minVal.st
    A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script384.st
    A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40384.st
    M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
    M System-Support.package/SmalltalkImage.class/class/initialization/initializeStartUpList.st

  Log Message:
  -----------
  40384
14506 Add class inst vars to hold SmallInteger class>>minVal and maxVal. 
	https://pharo.fogbugz.com/f/cases/14506

http://files.pharo.org/image/40/40384.zip

GitHub | 24 Nov 17:11 2014

[pharo-project/pharo-core]

  Branch: refs/tags/40384
  Home:   https://github.com/pharo-project/pharo-core

Gmane