Re: [Pharo-users] Iceberg: Installing a baseline from a self hosted Git/Gitea repository branch

[Offray Vladimir Luna Cárdenas]

Thanks a lot Christophe! It worked like a charm. Now I'm able to build a
shareable installation baseline that uses external git repositories not
hosted in the oligopolistic providers by downloading them with Iceberg
and loading from the hard disk with Metacello. I have updated the
Grafoscopio readme with the new installation procedure[1]

[1] https://mutabit.com/repos.fossil/grafoscopio/doc/tip/readme.md.html

Now, as I'm using that pattern for almost all my baselines (as they're
not hosted on GitHub, GitLab or Bitbucked), I would like to create some
kind of Metacello "plugin" that extends its vocabulary to load several
repositories in that way. I will be using a Pharo MOOC lesson from
Stephan where he extended numbers to understand tabletop RPG vocabulary,
but with Pharo 8. I wouldn't mind to host this on GitHub to make it
easily loadable, as it would open the door to any non-GitHub repository
and I will share the "plugin" here. Maybe it can be made a part of
official Metacello.

My point is that this short and key explanation inspires me to learn how
to collaborate in more core technologies behind Pharo and to share my
plans, advances and questions. So, thanks again.

Cheers,

Offray


On 16/07/20 4:24 p. m., Christophe Demarey wrote:
> Hi Offray,
>
> You can also use something like:
> location := FileLocator localDirectory / 'iceberg' / 'pharo-contributions' / 
> 'taskit'.
> (IceRepositoryCreator new 
>   location: location;
>   remote: (IceGitRemote url: 
> 'https://github.com/pharo-contributions/taskit.git');
>   createRepository)
> register.
>
> Metacello new
>   repository: 'gitlocal://', location fullName;
>   baseline: 'TaskIt';
>   load
>
> Regards,
> Christophe
>
>> Le 16 juil. 2020 à 20:04, Offray Vladimir Luna Cárdenas 
>>  a écrit :
>>
>> Hi Pierce,
>>
>> I'm loading the stuff in the self Gitea repositories from local copies
>> and in the order I know they are needed. So in a sense I following a
>> similar behavior as yours (but I will use the `tonel:///` trick now when
>> needed, thanks for it).
>>
>> My problem is with sharing my baseline with others to ease their
>> installation of the packages I develop, without using Git oligopolistic
>> providers (GitHub, GitLab and Bitbucket), but instead self hosted
>> community Gitea instances.
>>
>> From this thread, I imagine that the path to follow is to extend the
>> Metacello Git providers to include Gitea instances. I will see how the
>> current ones are implemented and what can I contribute using them as a
>> template for new providers and see how to contribute this back to Pharo
>> as a Metacello "plugin". I will share advances and questions here.
>>
>> Cheers,
>>
>> Offray
>>
>> On 15/07/20 10:19 p. m., Pierce Ng wrote:
>>> On Wed, Jul 15, 2020 at 08:41:04AM -0500, Offray Vladimir Luna Cárdenas 
>>> wrote:
 So, a better question would be: Is possible to load programatically (via
 a code snippet) using Iceberg, Monticello or something else a baseline
 that installs a project and its dependencies and is hosted in an
 independent Git provider? How can self hosted git repositories
 containing baselines be loaded?
>>> Hi Offray,
>>>
>>> I don't define dependencies in baselines for stuff in my self-hosted
>>> Gitea because I work on them myself and I know their interdependencies.
>>> And since I am working on them, they are all locally checked out.
>>>
>>> I load my stuff in the correct order like this:
>>>
>>>  Metacello new
>>>baseline: 'StuffOne';
>>>repository: 'tonel:///home/pierce/work/git/StuffOne/src';
>>>load.
>>>
>>>  Metacello new
>>>baseline: 'StuffTwo';
>>>repository: 'tonel:///home/pierce/work/git/StuffTwo/src';
>>>load.
>>>
>>> Here StuffTwo is dependent on StuffOne. To be clear, I have written
>>> baselines for StuffOne and StuffTwo, which is how I am loading them
>>> here. I'm just not defining in StuffTwo's baseline that StuffOne is a
>>> dependency.
>>>
>>> For me this is more agile because I only need to edit my load snippet
>>> and I get immediate feedback by running it.  The Git repo roundtripping
>>> of fixing up dependencies in baselines OTOH feels more like the
>>> edit-compile-test cycle.  Eventually if/when I publish StuffOne and
>>> StuffTwo, I do have to define the dependencies but it'll be easy because
>>> then they'll be on Github.
>>>
>>> Pierce
>>>
>>>
>>
>

Re: [Pharo-users] UFFI asynchronous callbacks

[Ben Coman]

Hi Asam,

On Sun, 19 Jul 2020 at 21:38, ASAM  wrote:
>
> Hello Ben,
>
> I quickly made a dummy DLL to limit the problem to the essentials.

Great idea.  A more generic example is attractive for people to
examine and help out.
I browsed the code but I'm sorry it needs a deeper expertise than I have.
Hopefully someone working on the threaded FFI will tune in.

In the meantime, it won't solve your query but you may find this
interesting to watch...
Strategies for Non-Blocking FFI
https://www.youtube.com/watch?v=L_QFwsNOMAc

cheers -ben

>
> I think my problem comes more from how I use the semaphore.
>
> I wanted to do that:
>
> only "semaphore signal",
> But that somehow doesn't work.
> Now i'm doing that "[ Processor yield. semaphore signal ] fork" (it work's)
> but i don't know if that's a good idea.
>
>
> ffiCallback
> ^ FFICallback signature: #( void #( uint32 foo ) ) block: [ :foo |
>   Transcript
>   show: 'API Funktion value: ' , foo asString, ' 
> activePriority:',
>   Processor activePriority asString; cr.
>
> "that's working"
>   [ Processor yield. semaphore signal ] fork.
>
>   "that usually works 80%."
>   "[ semaphore signal ] fork"
>
>   "that crashes pharo almost always."
>   "semaphore signal"
> ]
>
> I also have a little problem, too. Why can I use my own C-Type UNUM32 at
> ...self ffiCall: #( T_ERROR StartMyThreadFunction(UNUM32 millisecondsToFire)
> ).
> But with FFICallback signature: # (void # (uint32 foo)) I get an error
> "Unable to resolve external type: UNUM32. Why is that?
>
> Thanks for your help.
>
> testDllForAsyncCallback.dll
> 
> testDllForAsyncCallback.cpp
> 
> testDllForAsyncCallback.h
> 
> testDllForAsyncCallback.h
> 
> UFFICallback.st 
> CTypes.st 
> 
>
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>

Re: [Pharo-users] UFFI asynchronous callbacks

[ASAM]

Hello Ben, 

I quickly made a dummy DLL to limit the problem to the essentials.

I think my problem comes more from how I use the semaphore.

I wanted to do that: 

only "semaphore signal",
But that somehow doesn't work.
Now i'm doing that "[ Processor yield. semaphore signal ] fork" (it work's)
but i don't know if that's a good idea.


ffiCallback
^ FFICallback signature: #( void #( uint32 foo ) ) block: [ :foo | 
  Transcript
  show: 'API Funktion value: ' , foo asString, ' 
activePriority:',
  Processor activePriority asString; cr.

"that's working"
  [ Processor yield. semaphore signal ] fork. 
  
  "that usually works 80%."
  "[ semaphore signal ] fork"
  
  "that crashes pharo almost always."
  "semaphore signal"  
]

I also have a little problem, too. Why can I use my own C-Type UNUM32 at
...self ffiCall: #( T_ERROR StartMyThreadFunction(UNUM32 millisecondsToFire)
). 
But with FFICallback signature: # (void # (uint32 foo)) I get an error
"Unable to resolve external type: UNUM32. Why is that?

Thanks for your help.

testDllForAsyncCallback.dll
  
testDllForAsyncCallback.cpp
  
testDllForAsyncCallback.h
  
testDllForAsyncCallback.h
  
UFFICallback.st   
CTypes.st   
 




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html