<div dir="ltr"><div class="gmail_quote"><div class="GmSign">On Fri, Sep 4, 2015 at 9:26 AM Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 4 September 2015 at 07:01, Tobias Pape <<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>> wrote:<br>
><br>
> On 04.09.2015, at 05:46, Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>> wrote:<br>
><br>
>>> I do think that anything is better than the current situation. A bucket of<br>
>>> any kind in an agreed upon location seems like a good place to start.<br>
>><br>
>> I totally agree!<br>
><br>
> what about<br>
><br>
> <a href="http://github.com/squeak-vm/plugins" rel="noreferrer" target="_blank">http://github.com/squeak-vm/plugins</a><br>
><br>
> or<br>
><br>
> <a href="http://github.com/squeak-smalltalk/vm-plugins" rel="noreferrer" target="_blank">http://github.com/squeak-smalltalk/vm-plugins</a><br>
<br>
My preferred choice: the organisation already exists.<br>
<br>
frank<br>
<br>
> Best<br>
> -tobias<br>
><br>
> PS: we should look at <a href="https://github.com/search?q=squeak+vm" rel="noreferrer" target="_blank">https://github.com/search?q=squeak+vm</a><br>
><br>
>><br>
>>> I<br>
>>> hadn't considered that plugins would need meta data or labels.<br>
>><br>
>> They could be put into a .zip file and stored and cataloged somewhere<br>
>> which would be a well-known place for Squeak. And, each plugin would<br>
>> be tagged with one or more hierarchical Category's to indicate the<br>
>> platform and whatever else we wanted...<br>
>><br>
>> And, if the plugin is compiled and hosted somewhere else, like GitHub,<br>
>> then the Squeak-well-known place should direct the user to THAT<br>
>> external place instead of hosting copies on <a href="http://squeak.org" rel="noreferrer" target="_blank">squeak.org</a> servers...<br>
>> Except as a backup, of course..<br>
>><br>
>> Hmm, if only we have something that could do all that... Oh wait,<br>
>> we do!!!! ;-)<br>
>><br>
>>> Perhaps the best thing is to leave it as an open question for a few weeks<br>
>>> before settling on any kind of solution. A common location for plugins is<br>
>>> about as far as my thinking takes me at the moment. I'm sure the collective<br>
>>> imagination of the community can come up with a better idea.<br>
>>><br>
>>> Chris<br>
>>><br>
>>><br>
>>> On 2015-09-03 10:07 PM, David T. Lewis wrote:<br>
>>>><br>
>>>> On Thu, Sep 03, 2015 at 09:05:07PM -0400, Chris Cunnington wrote:<br>
>>>>><br>
>>>>> This community needs a repository for plugins. A directory at<br>
>>>>> <a href="http://ftp.squeak.org" rel="noreferrer" target="_blank">http://ftp.squeak.org</a> ought to do it.<br>
>>>>><br>
>>>>> If I want to try Alien I need the plugin. Where am I going to get that?<br>
>>>>> I could get VMMaker, read NewSqueakIA32ABIPlugin three times to see it<br>
>>>>> is not saying Newspeak and realize it compiles a plugin called IA32ABI,<br>
>>>>> which - coincidentally - is the name of the plugin the error Alien<br>
>>>>> exampleCqsort will gives me. (NewSqueakIA32ABIPlugin class>> moduleName<br>
>>>>> returns IA32ABI).<br>
>>>>><br>
>>>>> Does anybody know what the Genie plugin does? Does Paul DeBrucker need<br>
>>>>> to store a BerkeleyDB plugin dll he got by emailing somebody on GitHub?<br>
>>>>><br>
>>>>> If I understand this correctly, if such a directory existed, then all a<br>
>>>>> person would need to do to try the above Alien code would be to download<br>
>>>>> a pre-compiled plugin from - say -<br>
>>>>> <a href="http://ftp.squeak/plugins/Alien/fooVersion" rel="noreferrer" target="_blank">http://ftp.squeak/plugins/Alien/fooVersion</a>, put it in their VM directory<br>
>>>>> and start the image. Then check with SmalltalkImage current<br>
>>>>> listLoadedModules to see if you're ready to go.<br>
>>>>><br>
>>>>> I nominate Fabio Niephaus to be the person the community can send<br>
>>>>> pre-compiled plugins for inclusion in such a directory. Eliot's been<br>
>>>>> banging away about Alien for some time [1]. If a person could go, get<br>
>>>>> the plugin and give the code shot, he could have more productive<br>
>>>>> conversations about Alien.<br>
>>>>><br>
>>>>> So, if, Eliot, you have a pre-compiled plugin for Alien, perhaps in an<br>
>>>>> idle moment, you could email it to Fabio? And when, Fabio, you've<br>
>>>>> created the directory in <a href="http://ftp.squeak.org" rel="noreferrer" target="_blank">http://ftp.squeak.org</a> you could announce it<br>
>>>>> here on Squeak-dev?<br>
>>>>><br>
>>>>> FWIW,<br>
>>>>><br>
>>>>> Chris<br>
>>>><br>
>>>> A word of caution:<br>
>>>><br>
>>>> I think the idea is good in principle, but it needs to be accompanied<br>
>>>> by a commitment by someone to do the hard work of keeping track of<br>
>>>> dependencies on the various flavors of OS, image word size, VM word size,<br>
>>>> spur/V3, and so forth. If someone would like to take that on, great.<br>
>>>> That said, we don't want to start a project that gets 80% completed, and<br>
>>>> then expect "the community" to do the rest of the work.<br>
>>>><br>
>>>> I cannot speak for Fabio, but I don't think it is fair for us to expect<br>
>>>> him to take on this kind of workload unless he has indicated an interest<br>
>>>> in doing it.<br>
>>>><br>
>>>> Maybe a restricted repository focused just on compiled plugins known<br>
>>>> to work with the Spur VM on a limited range of OS flavors would be helpful<br>
>>>> at this stage. It probably does not belong on <a href="http://ftp.squeak.org" rel="noreferrer" target="_blank">ftp.squeak.org</a>, but it could<br>
>>>> be a very useful resource if someone (Chris Cunnington?) wants to set it<br>
>>>> up.<br>
>>>><br>
>>>> Dave<br>
>>>><br>
>>>><br>
>>>>> [1] <a href="http://wiki.squeak.org/squeak/uploads/6100/" rel="noreferrer" target="_blank">http://wiki.squeak.org/squeak/uploads/6100/</a><br>
>>>>><br>
>>>>> On 2015-09-03 7:07 PM, Eliot Miranda wrote:<br>
>>>>>><br>
>>>>>> Hi Craig,<br>
>>>>>><br>
>>>>>> you need Alien-eem.24<br>
>>>>>><br>
>>>>>> Here's Alien class>>exampleCqsort<br>
>>>>>> "Call the libc qsort function (which requires a callback)."<br>
>>>>>> "Alien exampleCqsort"<br>
>>>>>> "(Time millisecondsToRun: [100 timesRepeat: [Alien exampleCqsort]]) /<br>
>>>>>> 100.0"<br>
>>>>>> | cb rand nElements sizeofDouble values orig sort |<br>
>>>>>> rand := Random new.<br>
>>>>>> values := Alien newC: (nElements := 100) * (sizeofDouble := 8).<br>
>>>>>> 1 to: values dataSize by: sizeofDouble do:<br>
>>>>>> [:i| values doubleAt: i put: rand next].<br>
>>>>>> orig := (1 to: values dataSize by: sizeofDouble) collect: [:i| values<br>
>>>>>> doubleAt: i].<br>
>>>>>> cb := Callback<br>
>>>>>> signature: #(int (*)(const void *, const void *))<br>
>>>>>> block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) sign].<br>
>>>>>> (Alien lookup: 'qsort' inLibrary: Alien libcName)<br>
>>>>>> primFFICallResult: nil<br>
>>>>>> with: values pointer<br>
>>>>>> with: nElements<br>
>>>>>> with: sizeofDouble<br>
>>>>>> with: cb thunk.<br>
>>>>>> sort := (1 to: values dataSize by: sizeofDouble) collect: [:i| values<br>
>>>>>> doubleAt: i].<br>
>>>>>> values free.<br>
>>>>>> ^orig -> sort<br>
>>>>>><br>
>>>>>> The above example uses Alien to make the callout. To use it with the<br>
>>>>>> FFI simply pass cb pointer as the argument as is done above.<br>
>>>>>><br>
>>>>>><br>
>>>>>> Implementation:<br>
>>>>>><br>
>>>>>> The way that it works is in two parts<br>
>>>>>> - the VM passes up a pointer to a structure from which all arguments,<br>
>>>>>> stacked and in registers (because the VM has copied the register args<br>
>>>>>> into the struct) can be accessed, and through which the result can be<br>
>>>>>> returned.<br>
>>>>>> - the image level provides marshalling methods that match the<br>
>>>>>> signature in the callback<br>
>>>>>><br>
>>>>>> So e.g. with a callback of<br>
>>>>>> Callback<br>
>>>>>> signature: #(int (*)(const void *, const void *))<br>
>>>>>> block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) sign]<br>
>>>>>> the marshalling methods are in Callback's signature protocol:<br>
>>>>>><br>
>>>>>> Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien<br>
>>>>>> <signature: #(int (*)(const void *, const void *)) abi: 'IA32'><br>
>>>>>> ^callbackContext wordResult:<br>
>>>>>> (block<br>
>>>>>> value: (Alien forPointer: (spAlien unsignedLongAt: 1))<br>
>>>>>> value: (Alien forPointer: (spAlien unsignedLongAt: 5)))<br>
>>>>>><br>
>>>>>> where spAlien is an Alien pointing to a VMCallbackContext32.<br>
>>>>>><br>
>>>>>> For ARM support we would add<br>
>>>>>><br>
>>>>>> Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien<br>
>>>>>> intRegArgs: regsAlien<br>
>>>>>> <signature: #(int (*)(const void *, const void *)) abi: 'ARMV5'><br>
>>>>>> ^callbackContext wordResult:<br>
>>>>>> (block<br>
>>>>>> value: (Alien forPointer: (regsAlien unsignedLongAt: 1))<br>
>>>>>> value: (Alien forPointer: (regsAlien unsignedLongAt: 5)))<br>
>>>>>><br>
>>>>>> Basically the idea is that the selector of the method doesn't matter<br>
>>>>>> except for the number of arguments. What's important is the pragma<br>
>>>>>> which defines the signature and the ABI for which this is a valid<br>
>>>>>> marshalling method.<br>
>>>>>><br>
>>>>>> When the callback is instantiated, Callback introspects to find the<br>
>>>>>> marshalling method that matches the signature. If one doesn't already<br>
>>>>>> exist you can write one. Hopefully we'll write an ABI compiler that<br>
>>>>>> will automatically generate these marshalling methods according to the<br>
>>>>>> platform's ABI, but for now its a manual process. But at least it's<br>
>>>>>> open and flexible. When the callback is invoked the evaluator is<br>
>>>>>> performed with the current callbackContext and pointer(s) to the<br>
>>>>>> arguments. There is a 32-bit and a 64-bit callback context, and it can<br>
>>>>>> have a stack pointer, integer register args and floating point<br>
>>>>>> register args. So it's general enough for any callback.<br>
>>>>>><br>
>>>>>> To pass back the result, a value is assigned into the struct via the<br>
>>>>>> accessor in the marshalling method and control returns to teh point<br>
>>>>>> where teh callback comes in, and this uses a primitive to return.<br>
>>>>>> Inside the callbackCOntext is a jmpbuf from a setjmp. The primitive<br>
>>>>>> longjmp's back to the entry point in the VM which extracts the result<br>
>>>>>> and the code for the kind of result and returns:<br>
>>>>>><br>
>>>>>> Callback class>>invokeCallbackContext: vmCallbackContextAddress<br>
>>>>>> "<Integer>" "^<FFICallbackReturnValue>"<br>
>>>>>> "The low-level entry-point for callbacks sent from the VM/IA32ABI<br>
>>>>>> plugin.<br>
>>>>>> Return via primReturnFromContext:through:. thisContext's sender is the<br>
>>>>>> call-out context."<br>
>>>>>> | callbackAlien type |<br>
>>>>>> callbackAlien := (Smalltalk wordSize = 4<br>
>>>>>> ifTrue: [VMCallbackContext32]<br>
>>>>>> ifFalse: [VMCallbackContext64])<br>
>>>>>> atAddress: vmCallbackContextAddress.<br>
>>>>>> [type := Callback evaluateCallbackForContext: callbackAlien]<br>
>>>>>> ifCurtailed: [self error: 'attempt to non-local return across a<br>
>>>>>> callback'].<br>
>>>>>> type ifNil:<br>
>>>>>> [type := 1. callbackAlien wordResult: -1].<br>
>>>>>> callbackAlien primReturnAs: type fromContext: thisContext<br>
>>>>>><br>
>>>>>> On Thu, Sep 3, 2015 at 5:22 AM, Craig Latta <<a href="mailto:craig@netjam.org" target="_blank">craig@netjam.org</a><br>
>>>>>> <mailto:<a href="mailto:craig@netjam.org" target="_blank">craig@netjam.org</a>>> wrote:<br>
>>>>>><br>
>>>>>><br>
>>>>>> Hi all--<br>
>>>>>><br>
>>>>>> I'd like to use a C shared library via FFI from Squeak or<br>
>>>>>> Pharo.<br>
>>>>>> Specifically, I want to call a C function which takes as one of its<br>
>>>>>> parameters a pointer to an array of callback function addresses.<br>
>>>>>> Does<br>
>>>>>> one of the FFI approaches floating around handle that, and provide a<br>
>>>>>> relatively pleasant mapping between Smalltalk block closures and C<br>
>>>>>> callback function addresses?<br>
>>>>>><br>
>>>>>> I was doing this so far in GemStone, but apparently its FFI<br>
>>>>>> only<br>
>>>>>> supports passing callback function addresses one at a time as direct<br>
>>>>>> parameters of C callouts. I suppose I could write a wrapper C<br>
>>>>>> library<br>
>>>>>> around the one I really want to use, that provides the callback<br>
>>>>>> setup<br>
>>>>>> interface that GemStone expects, but whenever I have to write actual<br>
>>>>>> C<br>
>>>>>> code I start to think "Hm, why don't I just use a Smalltalk VM for<br>
>>>>>> which<br>
>>>>>> I have the source?" :) All the fancy distributed object-database<br>
>>>>>> stuff<br>
>>>>>> that my project also wants can wait for a bit.<br>
>>>>>><br>
>>>>>><br>
>>>>>> thanks!<br>
>>>>>><br>
>>>>>> -C<br>
>>>>>><br>
>>>>>> --<br>
>>>>>> Craig Latta<br>
>>>>>> <a href="http://netjam.org" rel="noreferrer" target="_blank">netjam.org</a> <<a href="http://netjam.org" rel="noreferrer" target="_blank">http://netjam.org</a>><br>
>>>>>> +31 6 2757 7177 <tel:%2B31%20%20%206%202757%207177> (SMS ok)<br>
>>>>>> + 1 415 287 3547 <tel:%2B%201%20415%20%20287%203547> (no SMS)<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> --<br>
>>>>>> _,,,^..^,,,_<br>
>>>>>> best, Eliot<br>
><br>
><br>
><br>
<br></blockquote><div><br></div><div>I'd agree that the best thing for now is to leave it as an open question</div><div>and then we should go for a solution that everyone feels comfortable</div><div>with.</div><div><br></div><div>I'm not sure though if a single GitHub repository will do the trick</div><div>considering the meta information mentioned by David.</div><div>However, we could e.g. use different branches for different Squeak</div><div>versions, but we really need to think this through.</div><div><br></div><div>A related question: how hard would it be to build plugins</div><div>automatically (e.g. on Travis CI or on AppVeyor) from source?</div><div><br></div></div></div>