Re: [Pharo-users] Woden-Roassal pharo5 inspector bugs

[Lusa Nicolas]

Hi,

thanks for the quick answer, I'll switch back to pharo4 for the moment.

Cheers,
Nicolas

Re: [Pharo-users] Editing Pillar

[Norbert Hartl]

I tried that a few weeks ago and it didn't work. Maybe I should try again?

Norbert

> Am 04.05.2015 um 23:42 schrieb Tudor Girba :
> 
> Take a look at the support from GT-Inspector:
> 
> http://www.humane-assessment.com/blog/writing-pillar-books-with-the-gtinspector/
>  
> 
> 
> Cheers,
> Doru
> 
> 
> 
> On Mon, May 4, 2015 at 2:09 PM, Norbert Hartl  > wrote:
> I know there are few threads about Pillar these days. I'm sorry if I'm 
> repeating another present question. What would be the best way to edit a 
> pillar file in the image. Is there some nice rubric editor or the like where 
> I can edit pillar syntax with highlighting? And has this something like the 
> preview the class comment in pillar stuff offers?
> 
> thanks,
> 
> Norbert
> 
> 
> 
> 
> 
> -- 
> www.tudorgirba.com 
> 
> "Every thing has its own flow"

Re: [Pharo-users] mac address on windows

[Usman Bhatti]

On Tue, May 5, 2015 at 7:34 PM, p...@highoctane.be 
wrote:

>
> On Tue, May 5, 2015 at 6:28 PM, Usman Bhatti 
> wrote:
>
>> I succeeded to do it by encapsulating the C routine as a DLL and doing an
>> FFI call from my image (as suggested by Guille).
>>
>
> At least there was a way!
>

Exactly :)


>
> Looks like this is the most controlled|debuggable way:
>   - get it working with C code out of Pharo
>   - make a bridge that can be used easily with FFI in a dll
>   - use that from Pharo with proven FFI
>
> Would NativeBoost work with your dll? Should.
>

I have read a few resources about Nativeboost but I am still naive to know
the difference between FFI and nativeboost. The FFI call I made to invoke
the DLL function looked similar to the nativeboost calls.


>
>
> I also tried to perform the nativeboost call by creating my structures in
>> Pharo. The function in Windows that can be used to retrieve mac address in
>> Windows: GetAdaptersInfo
>> 
>>  that
>> accepts a PIP_ADAPTER_INFO
>> 
>>  structure.
>> I subclassed NBExternalStructure to define this struct and the other used
>> by it in the image but my NB call returned with 87 code (Invalid parameter)
>> and it was impossible to debug. However, I would like to make this thing
>> work to understand what went wrong.
>>
>
> Has this something to do with 32|64 bit library complications?
>

Not exactly. For me, it was more related to the fact that I had to map a
complex C struct in Pharo. Here is an excerpt of the definition from MSDN:

typedef struct _IP_ADAPTER_INFO {
  struct _IP_ADAPTER_INFO  *Next;
 ...
  PIP_ADDR_STRING CurrentIpAddress;
  IP_ADDR_STRING  GatewayList;
...
}

So, I had to define three external structures (all names in capitals) and I
did the effort but in the end I got an error code that I could not debug in
the image. Hence, I gave up and opted to go in the native environment. But
I would like someone knowledgable to have a look at my nativeboost code
 because the nativeboost approach is more simple (everything's in the
image).



usman


>
> Phil
>
>>
>> With ProcessWrapper, I could not load the classes essential for making
>> the plugin work.
>>
>> HTH,
>>
>> Usman
>>
>>
>>
>>
>> On Mon, May 4, 2015 at 2:54 PM, Ben Coman  wrote:
>>
>>> As a complete newb to VM building I found this fairly straight forward
>>> (on a Mac btw).
>>> https://github.com/pharo-project/pharo-vm
>>> cheers -ben
>>>
>>> On Mon, May 4, 2015 at 5:28 PM, Usman Bhatti 
>>> wrote:
>>>


 On Sun, May 3, 2015 at 4:22 PM, Pierce Ng 
 wrote:

> On Sat, May 02, 2015 at 03:55:47PM +0200, Usman Bhatti wrote:
> > 1/ OSProcess: I tried  (PipeableOSProcess command: 'ipconfig /all')
> output.
>
> I have used http://www.smalltalkhub.com/#!/~hernan/ProcessWrapper
> successfully
> back when I was on Windows using some now-ancient version of Pharo.
>

 I had initially discarded the idea of using this project because it
 required a plugin and the information of the plugin was outdated on
 squeaksource. However, having evaluated superficially the complexity of
 doing it with nativeboost (because too many external c struct involved in
 the call), I would like to see if I am better off using this wrapper.

 I loaded it with:

 Gofer it
   url: 'http://www.smalltalkhub.com/mc/hernan/ProcessWrapper/main';
   package: 'ProcessWrapper-Core';
   package: 'ProcessWrapper-Plugin';
   package: 'ProcessWrapper-Tests';
   load.

 But the plugins wont load because it requires the
 class SmartSyntaxInterpreterPlugin and apparently this file is a part of
 the VMMaker. Is there any recent config for VMMaker in Pharo because this
 one looks outdated:

 http://pharo.gemtalksystems.com/book/Virtual-Machine/Building/VMMakerTool/





>
> Pierce
>
>

>>>
>>
>
>
>
>
>
>

Re: [Pharo-users] mac address on windows

[Usman Bhatti]

On Tue, May 5, 2015 at 7:54 PM, Thierry Goubier 
wrote:

> Le 05/05/2015 18:28, Usman Bhatti a écrit :
>
>> I succeeded to do it by encapsulating the C routine as a DLL and doing
>> an FFI call from my image (as suggested by Guille).
>>
>> I also tried to perform the nativeboost call by creating my structures
>> in Pharo. The function in Windows that can be used to retrieve mac
>> address in Windows: GetAdaptersInfo
>> <
>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa365917%28v=vs.85%29.aspx>
>> that
>> accepts a PIP_ADAPTER_INFO
>> <
>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa366062(v=vs.85).aspx>
>> structure.
>> I subclassed NBExternalStructure to define this struct and the other
>> used by it in the image but my NB call returned with 87 code (Invalid
>> parameter) and it was impossible to debug. However, I would like to make
>> this thing work to understand what went wrong.
>>
>> With ProcessWrapper, I could not load the classes essential for making
>> the plugin work.
>>
>
> ProcessWrapper is loaded with GitFileTree in Pharo3 and Pharo4.
>
> Can you detail what doesn't work?


When doing:

Gofer it
  url: 'http://www.smalltalkhub.com/mc/hernan/ProcessWrapper/main';
  package: 'ProcessWrapper-Core';
  package: 'ProcessWrapper-Plugin';
  package: 'ProcessWrapper-Tests';
  load.

Plugin classes couldn't be loaded because they require
SmartSyntaxInterpreterPlugin
class. I found a few posts mentioning that the class should be present in
the VMMaker but I didn't dig further.

regards.


>
>
> Thierry
>
>
>> HTH,
>>
>> Usman
>>
>>
>>
>>
>> On Mon, May 4, 2015 at 2:54 PM, Ben Coman > > wrote:
>>
>> As a complete newb to VM building I found this fairly straight
>> forward (on a Mac btw).
>> https://github.com/pharo-project/pharo-vm
>> cheers -ben
>>
>> On Mon, May 4, 2015 at 5:28 PM, Usman Bhatti > > wrote:
>>
>>
>>
>> On Sun, May 3, 2015 at 4:22 PM, Pierce Ng > > wrote:
>>
>> On Sat, May 02, 2015 at 03:55:47PM +0200, Usman Bhatti wrote:
>> > 1/ OSProcess: I tried  (PipeableOSProcess command:
>> 'ipconfig /all') output.
>>
>> I have used
>> http://www.smalltalkhub.com/#!/~hernan/ProcessWrapper
>> successfully
>> back when I was on Windows using some now-ancient version of
>> Pharo.
>>
>>
>> I had initially discarded the idea of using this project because
>> it required a plugin and the information of the plugin was
>> outdated on squeaksource. However, having evaluated
>> superficially the complexity of doing it with nativeboost
>> (because too many external c struct involved in the call), I
>> would like to see if I am better off using this wrapper.
>>
>> I loaded it with:
>>
>> Gofer it
>>url: '
>> http://www.smalltalkhub.com/mc/hernan/ProcessWrapper/main';
>>package: 'ProcessWrapper-Core';
>>package: 'ProcessWrapper-Plugin';
>>package: 'ProcessWrapper-Tests';
>>load.
>>
>> But the plugins wont load because it requires the
>> class SmartSyntaxInterpreterPlugin and apparently this file is a
>> part of the VMMaker. Is there any recent config for VMMaker in
>> Pharo because this one looks outdated:
>>
>> http://pharo.gemtalksystems.com/book/Virtual-Machine/Building/VMMakerTool/
>>
>>
>>
>>
>> Pierce
>>
>>
>>
>>
>>
>
>

Re: [Pharo-users] mac address on windows

[Nicolai Hess]

2015-05-06 9:53 GMT+02:00 Usman Bhatti :

>
>
> On Tue, May 5, 2015 at 7:34 PM, p...@highoctane.be 
> wrote:
>
>>
>> On Tue, May 5, 2015 at 6:28 PM, Usman Bhatti 
>> wrote:
>>
>>> I succeeded to do it by encapsulating the C routine as a DLL and doing
>>> an FFI call from my image (as suggested by Guille).
>>>
>>
>> At least there was a way!
>>
>
> Exactly :)
>
>
>>
>> Looks like this is the most controlled|debuggable way:
>>   - get it working with C code out of Pharo
>>   - make a bridge that can be used easily with FFI in a dll
>>   - use that from Pharo with proven FFI
>>
>> Would NativeBoost work with your dll? Should.
>>
>
> I have read a few resources about Nativeboost but I am still naive to know
> the difference between FFI and nativeboost. The FFI call I made to invoke
> the DLL function looked similar to the nativeboost calls.
>
>
>>
>>
>> I also tried to perform the nativeboost call by creating my structures in
>>> Pharo. The function in Windows that can be used to retrieve mac address in
>>> Windows: GetAdaptersInfo
>>> 
>>>  that
>>> accepts a PIP_ADAPTER_INFO
>>> 
>>>  structure.
>>> I subclassed NBExternalStructure to define this struct and the other used
>>> by it in the image but my NB call returned with 87 code (Invalid parameter)
>>> and it was impossible to debug. However, I would like to make this thing
>>> work to understand what went wrong.
>>>
>>
>> Has this something to do with 32|64 bit library complications?
>>
>
> Not exactly. For me, it was more related to the fact that I had to map a
> complex C struct in Pharo. Here is an excerpt of the definition from MSDN:
>
> typedef struct _IP_ADAPTER_INFO {
>   struct _IP_ADAPTER_INFO  *Next;
>  ...
>   PIP_ADDR_STRING CurrentIpAddress;
>   IP_ADDR_STRING  GatewayList;
> ...
> }
>
> So, I had to define three external structures (all names in capitals) and
> I did the effort but in the end I got an error code that I could not debug
> in the image. Hence, I gave up and opted to go in the native environment.
> But I would like someone knowledgable to have a look at my nativeboost code
>  because the nativeboost approach is more simple (everything's in the
> image).
>

I can have a look.

btw. for what do you need the mac address?



>
>
>
> usman
>
>
>>
>> Phil
>>
>>>
>>> With ProcessWrapper, I could not load the classes essential for making
>>> the plugin work.
>>>
>>> HTH,
>>>
>>> Usman
>>>
>>>
>>>
>>>
>>> On Mon, May 4, 2015 at 2:54 PM, Ben Coman  wrote:
>>>
 As a complete newb to VM building I found this fairly straight forward
 (on a Mac btw).
 https://github.com/pharo-project/pharo-vm
 cheers -ben

 On Mon, May 4, 2015 at 5:28 PM, Usman Bhatti 
 wrote:

>
>
> On Sun, May 3, 2015 at 4:22 PM, Pierce Ng 
> wrote:
>
>> On Sat, May 02, 2015 at 03:55:47PM +0200, Usman Bhatti wrote:
>> > 1/ OSProcess: I tried  (PipeableOSProcess command: 'ipconfig /all')
>> output.
>>
>> I have used http://www.smalltalkhub.com/#!/~hernan/ProcessWrapper
>> successfully
>> back when I was on Windows using some now-ancient version of Pharo.
>>
>
> I had initially discarded the idea of using this project because it
> required a plugin and the information of the plugin was outdated on
> squeaksource. However, having evaluated superficially the complexity of
> doing it with nativeboost (because too many external c struct involved in
> the call), I would like to see if I am better off using this wrapper.
>
> I loaded it with:
>
> Gofer it
>   url: 'http://www.smalltalkhub.com/mc/hernan/ProcessWrapper/main';
>   package: 'ProcessWrapper-Core';
>   package: 'ProcessWrapper-Plugin';
>   package: 'ProcessWrapper-Tests';
>   load.
>
> But the plugins wont load because it requires the
> class SmartSyntaxInterpreterPlugin and apparently this file is a part of
> the VMMaker. Is there any recent config for VMMaker in Pharo because this
> one looks outdated:
>
> http://pharo.gemtalksystems.com/book/Virtual-Machine/Building/VMMakerTool/
>
>
>
>
>
>>
>> Pierce
>>
>>
>

>>>
>>
>>
>>
>>
>>
>>
>

Re: [Pharo-users] mac address on windows

[Thierry Goubier]

2015-05-06 9:57 GMT+02:00 Usman Bhatti :

> On Tue, May 5, 2015 at 7:54 PM, Thierry Goubier  > wrote:
>
>> Le 05/05/2015 18:28, Usman Bhatti a écrit :
>>
>>> I succeeded to do it by encapsulating the C routine as a DLL and doing
>>> an FFI call from my image (as suggested by Guille).
>>>
>>> I also tried to perform the nativeboost call by creating my structures
>>> in Pharo. The function in Windows that can be used to retrieve mac
>>> address in Windows: GetAdaptersInfo
>>> <
>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa365917%28v=vs.85%29.aspx>
>>> that
>>> accepts a PIP_ADAPTER_INFO
>>> <
>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa366062(v=vs.85).aspx>
>>> structure.
>>> I subclassed NBExternalStructure to define this struct and the other
>>> used by it in the image but my NB call returned with 87 code (Invalid
>>> parameter) and it was impossible to debug. However, I would like to make
>>> this thing work to understand what went wrong.
>>>
>>> With ProcessWrapper, I could not load the classes essential for making
>>> the plugin work.
>>>
>>
>> ProcessWrapper is loaded with GitFileTree in Pharo3 and Pharo4.
>>
>> Can you detail what doesn't work?
>
>
> When doing:
>
> Gofer it
>   url: 'http://www.smalltalkhub.com/mc/hernan/ProcessWrapper/main';
>   package: 'ProcessWrapper-Core';
>   package: 'ProcessWrapper-Plugin';
>   package: 'ProcessWrapper-Tests';
>   load.
>
> Plugin classes couldn't be loaded because they require 
> SmartSyntaxInterpreterPlugin
> class. I found a few posts mentioning that the class should be present in
> the VMMaker but I didn't dig further.
>

Ok.

Metacello new
  configuration: 'ProcessWrapper';
  repository: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPhar40/Main';
  load

Is what I use.

As far as I can see, ProcessWrapper-Plugin has little use; it contains only
primitives which are in ProcessWrapper-Core. The plugin is automatically
downloaded when you use the configuration, which means your Gofer script
doesn't work.

The configuration in the Meta repository is one version late compared to
the Smalltalkhub repository configuration. Hernan, should I update the
configuration in the Meta repository?

Regards,

Thierry


>
> regards.
>
>
>>
>>
>> Thierry
>>
>>
>>> HTH,
>>>
>>> Usman
>>>
>>>
>>>
>>>
>>> On Mon, May 4, 2015 at 2:54 PM, Ben Coman >> > wrote:
>>>
>>> As a complete newb to VM building I found this fairly straight
>>> forward (on a Mac btw).
>>> https://github.com/pharo-project/pharo-vm
>>> cheers -ben
>>>
>>> On Mon, May 4, 2015 at 5:28 PM, Usman Bhatti >> > wrote:
>>>
>>>
>>>
>>> On Sun, May 3, 2015 at 4:22 PM, Pierce Ng >> > wrote:
>>>
>>> On Sat, May 02, 2015 at 03:55:47PM +0200, Usman Bhatti wrote:
>>> > 1/ OSProcess: I tried  (PipeableOSProcess command:
>>> 'ipconfig /all') output.
>>>
>>> I have used
>>> http://www.smalltalkhub.com/#!/~hernan/ProcessWrapper
>>> successfully
>>> back when I was on Windows using some now-ancient version of
>>> Pharo.
>>>
>>>
>>> I had initially discarded the idea of using this project because
>>> it required a plugin and the information of the plugin was
>>> outdated on squeaksource. However, having evaluated
>>> superficially the complexity of doing it with nativeboost
>>> (because too many external c struct involved in the call), I
>>> would like to see if I am better off using this wrapper.
>>>
>>> I loaded it with:
>>>
>>> Gofer it
>>>url: '
>>> http://www.smalltalkhub.com/mc/hernan/ProcessWrapper/main';
>>>package: 'ProcessWrapper-Core';
>>>package: 'ProcessWrapper-Plugin';
>>>package: 'ProcessWrapper-Tests';
>>>load.
>>>
>>> But the plugins wont load because it requires the
>>> class SmartSyntaxInterpreterPlugin and apparently this file is a
>>> part of the VMMaker. Is there any recent config for VMMaker in
>>> Pharo because this one looks outdated:
>>>
>>> http://pharo.gemtalksystems.com/book/Virtual-Machine/Building/VMMakerTool/
>>>
>>>
>>>
>>>
>>> Pierce
>>>
>>>
>>>
>>>
>>>
>>
>>
>

[Pharo-users] WebSocket and Proxying ...

[itli...@schrievkrom.de]

Hello,

I'm playing with WebSockets under Pharo4 and this works as expected -
when using Pharo4 alone (using the Zinc packages).

But I did not get it to work, when e.g. doing a proxying via nginx (I
did not check it with Apache).

Actually Pharo4 seems to receive some stuff, because the WebSocket of
Pharo4 stuff does not work as expected after first proxying attempts.

Has anyone experience with that ?

Marten

Re: [Pharo-users] WebSocket and Proxying ...

[Sven Van Caekenberghe]

Marten,

> On 06 May 2015, at 10:15, itli...@schrievkrom.de wrote:
> 
> Hello,
> 
> I'm playing with WebSockets under Pharo4 and this works as expected -
> when using Pharo4 alone (using the Zinc packages).
> 
> But I did not get it to work, when e.g. doing a proxying via nginx (I
> did not check it with Apache).
> 
> Actually Pharo4 seems to receive some stuff, because the WebSocket of
> Pharo4 stuff does not work as expected after first proxying attempts.
> 
> Has anyone experience with that ?
> 
> Marten

Proxying the WebSockets protocol is not easy, nor implemented everywhere, like 
HTTP is. This makes sense if you think about it, a WebSocket connection is a 
permanent connection, which takes resources, this is not something most servers 
like.

So it is more difficult.

Did you see/try http://nginx.org/en/docs/http/websocket.html ?

(I did not try it)

Sven

Re: [Pharo-users] mac address on windows

[Usman Bhatti]

On Wed, May 6, 2015 at 9:58 AM, Nicolai Hess  wrote:

>
>
> 2015-05-06 9:53 GMT+02:00 Usman Bhatti :
>
>>
>>
>> On Tue, May 5, 2015 at 7:34 PM, p...@highoctane.be 
>> wrote:
>>
>>>
>>> On Tue, May 5, 2015 at 6:28 PM, Usman Bhatti 
>>> wrote:
>>>
 I succeeded to do it by encapsulating the C routine as a DLL and doing
 an FFI call from my image (as suggested by Guille).

>>>
>>> At least there was a way!
>>>
>>
>> Exactly :)
>>
>>
>>>
>>> Looks like this is the most controlled|debuggable way:
>>>   - get it working with C code out of Pharo
>>>   - make a bridge that can be used easily with FFI in a dll
>>>   - use that from Pharo with proven FFI
>>>
>>> Would NativeBoost work with your dll? Should.
>>>
>>
>> I have read a few resources about Nativeboost but I am still naive to
>> know the difference between FFI and nativeboost. The FFI call I made to
>> invoke the DLL function looked similar to the nativeboost calls.
>>
>>
>>>
>>>
>>> I also tried to perform the nativeboost call by creating my structures
 in Pharo. The function in Windows that can be used to retrieve mac address
 in Windows: GetAdaptersInfo
 
  that
 accepts a PIP_ADAPTER_INFO
 
  structure.
 I subclassed NBExternalStructure to define this struct and the other used
 by it in the image but my NB call returned with 87 code (Invalid parameter)
 and it was impossible to debug. However, I would like to make this thing
 work to understand what went wrong.

>>>
>>> Has this something to do with 32|64 bit library complications?
>>>
>>
>> Not exactly. For me, it was more related to the fact that I had to map a
>> complex C struct in Pharo. Here is an excerpt of the definition from MSDN:
>>
>> typedef struct _IP_ADAPTER_INFO {
>>   struct _IP_ADAPTER_INFO  *Next;
>>  ...
>>   PIP_ADDR_STRING CurrentIpAddress;
>>   IP_ADDR_STRING  GatewayList;
>> ...
>> }
>>
>> So, I had to define three external structures (all names in capitals) and
>> I did the effort but in the end I got an error code that I could not debug
>> in the image. Hence, I gave up and opted to go in the native environment.
>> But I would like someone knowledgable to have a look at my nativeboost code
>>  because the nativeboost approach is more simple (everything's in the
>> image).
>>
>
> I can have a look.
>
> btw. for what do you need the mac address?
>

hardware lock.



>
>
>
>>
>>
>>
>> usman
>>
>>
>>>
>>> Phil
>>>

 With ProcessWrapper, I could not load the classes essential for making
 the plugin work.

 HTH,

 Usman




 On Mon, May 4, 2015 at 2:54 PM, Ben Coman  wrote:

> As a complete newb to VM building I found this fairly straight forward
> (on a Mac btw).
> https://github.com/pharo-project/pharo-vm
> cheers -ben
>
> On Mon, May 4, 2015 at 5:28 PM, Usman Bhatti 
> wrote:
>
>>
>>
>> On Sun, May 3, 2015 at 4:22 PM, Pierce Ng 
>> wrote:
>>
>>> On Sat, May 02, 2015 at 03:55:47PM +0200, Usman Bhatti wrote:
>>> > 1/ OSProcess: I tried  (PipeableOSProcess command: 'ipconfig
>>> /all') output.
>>>
>>> I have used http://www.smalltalkhub.com/#!/~hernan/ProcessWrapper
>>> successfully
>>> back when I was on Windows using some now-ancient version of Pharo.
>>>
>>
>> I had initially discarded the idea of using this project because it
>> required a plugin and the information of the plugin was outdated on
>> squeaksource. However, having evaluated superficially the complexity of
>> doing it with nativeboost (because too many external c struct involved in
>> the call), I would like to see if I am better off using this wrapper.
>>
>> I loaded it with:
>>
>> Gofer it
>>   url: 'http://www.smalltalkhub.com/mc/hernan/ProcessWrapper/main';
>>   package: 'ProcessWrapper-Core';
>>   package: 'ProcessWrapper-Plugin';
>>   package: 'ProcessWrapper-Tests';
>>   load.
>>
>> But the plugins wont load because it requires the
>> class SmartSyntaxInterpreterPlugin and apparently this file is a part of
>> the VMMaker. Is there any recent config for VMMaker in Pharo because this
>> one looks outdated:
>>
>> http://pharo.gemtalksystems.com/book/Virtual-Machine/Building/VMMakerTool/
>>
>>
>>
>>
>>
>>>
>>> Pierce
>>>
>>>
>>
>

>>>
>>>
>>>
>>>
>>>
>>>
>>
>

Re: [Pharo-users] Problems in switching from Moose 5.0 (Pharo 3) to Moose 5.1 (Pharo 4)

[Blondeau Vincent]

De : Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] De la part de 
PBKResearch
Envoyé : mardi 5 mai 2015 18:01
À : pharo-users@lists.pharo.org
Objet : [Pharo-users] Problems in switching from Moose 5.0 (Pharo 3) to Moose 
5.1 (Pharo 4)
Hello,

I have been working with Moose 5.0 on a project involving natural language 
processing. I used TextLint to parse the input, just because it contained a set 
of parsers which gave output in a convenient form. I have read all about the 
virtues of Pharo 4, and decided to give it a try, so I set out to reproduce the 
earlier results. I have run into a number of problems - basically I haven't 
been able to get anywhere. I realise TextLint is rather antique, but basically 
as I use it it is just a set of PetitParser parsers, so I can't see a problem.

I have boiled the problems down to a few test cases, not realistic bits of my 
work but just to show the essential points.


1.  Environment: Windows 7 Professional (64 bit version).

2.  Download and install latest Pharo 4 - Latest update: #40612. This is 
just to get an up to date VM.

3.  Download latest Moose 5.1 image and unzip into same folder as Pharo 4. 
On opening the Moose 5.1 image it also shows Latest update: #40612. (I have to 
ignore Firefox's hysterical warnings that the INRIA site does not have a valid 
security certificate.)

4.  Load TextLint into the image. Can't get 'ConfigurationofTextLint' to 
work, so load TextLInt-Model-JorgeRessia.225.mcz and TextLint-Tests-lr.166.mcz 
via the Monticello Browser. This is the same as I used in my earlier Moose 5.0 
image, where it worked as expected.

The ConfigurationofTextLint doesn't not load because it can't found the project 
NEC which is not at 'http://ss3.gemstone.com/ss/NEC', it has to be changed in 
ConfigurationOfGlamour>>default:.

Your configuration should not load Glamour because it is already included in 
the Moose image.

5.  Open a playground, enter:

PPToken on: 'test'.

and select 'Inspect it'. The inspector halts with message: 'MNU 
ByteString>>find AnySubstring:startingAt:'  Basic Inspect works as expected. 
Does this look like the problem raised by Nicolas Lusa today?

Seems resolved on latest Moose5.1 (#874) on Pharo #40613.

6.  Enter in the playground:

word := (TLTextTokenizer parse: 'test' startingAt: #word) at: 1.

(The tokenizer gives an array of tokens, so we need to select the first - and 
only - one.) Basic Inspect confirms that 'word' is a PPToken, as expected.

The code doesn't work, did you mean : (TLTextTokenizer parse: 'test' 
startingAt: #word) parsedValue at: 1 ?

7.  Enter in the playground:

TLWord with: word.

Select 'Do it'. The image becomes completely unresponsive, and appears to be in 
a tight loop. Only way out is to click the Windows red X and say yes to exit 
without saving. Restarting, get to the same point and select 'Debug it'. Trace 
it to TLSyntacticElement>>initializeWith: aToken, where the only line of code 
is: 'token := aToken'. Again a complete lockup.

Do ALT+. as soon you execute the method, you should be able to find the error. 
By the way it seems that in TLSyntacticElement>>text, value has to be replaced 
by inputValue (value is deprecated, and the notify event seems to loop...). It 
seems to work after that.

Sorry for the lengthy details; I just hope there is enough there to enable 
someone to diagnose the problem(s). Any help gratefully received. Meanwhile I 
am back to the Pharo 3 version.
Clear details, though. I think you can go back to Pharo 4.

Thanks
You're welcome,

Vincent Blondeau

Peter Kenny





Ce message et les pièces jointes sont confidentiels et réservés à l'usage 
exclusif de ses destinataires. Il peut également être protégé par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant 
être assurée sur Internet, la responsabilité de Worldline ne pourra être 
recherchée quant au contenu de ce message. Bien que les meilleurs efforts 
soient faits pour maintenir cette transmission exempte de tout virus, 
l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne 
saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, the Worldline liability cannot be triggered for the 
message content. Although the sender endeavours to maintain a computer 
virus-free network, the sender does not warrant that this transmission is 
virus-free and will not be liable for any damages resulting from any virus 
transmitted.

Re: [Pharo-users] [ANN] Idea icon pack now in Configuration Browser

[Esteban Lorenzano]

I made a pass and changed flag and halt icons. 
Not sure, but they will *probably* work better… we’ll see. 

Esteban

> On 05 May 2015, at 18:32, Esteban Lorenzano  wrote:
> 
> 
>> On 05 May 2015, at 18:04, p...@highoctane.be  
>> wrote:
>> 
>> While we are at it, the icon for methods with a 
>> 
>> self flag: #SomeSymbol
>> 
>> is a bit hard.. Can't we have the flags back? The danger sign isn't too 
>> appropriate.
> 
> nope, the flags are gone for good… they were ugly even before :) (and they 
> have white borders so not good for dark theme)
> the sign I’m using is a “warning” sign… is kind of appropriate, but I can 
> search for something less “big".
> 
>> and 
>> 
>> self halt.
>> 
>> which gives a kind of strange circle isn't too nice either.
> 
> is a breakpoint sign in Idea set… so again… is appropriate but probably to 
> big or strong. I can search something better, but I do not ensure a result :)
> 
>> 
>> Are there icons in the set that would fit better?
> 
> Well… those are the ones I found more appropriate, I did not chose them 
> random or without thought. 
> But, I will do a re-pass… and maybe I will modify some icon. 
> Not that I have all the time of the world, but eventually I will have 
> insomnia again :)
> 
> Esteban
> 
>> 
>> Phil
>> 
>> 
>> 
>> On Tue, May 5, 2015 at 5:59 PM, Offray Vladimir Luna Cárdenas 
>> mailto:off...@riseup.net>> wrote:
>> Hi,
>> 
>> El 04/05/15 a las 18:05, Esteban Lorenzano escribió:
>> 
>> On 05 May 2015, at 01:10, Offray Vladimir Luna Cárdenas > 
>> >> wrote:
>> 
>> May be the small icon of the glasses works better now that the print preview
>> is not "polluting" the writing of code, but has a tooltip with glasses on it.
>> 
>> no, because that’s the icon for “inspect” and what you see there is is
>> playground specific: is showing the result and offering you the possibility 
>> of
>> inspect it, yet the glasses.
>> 
>> Esteban
>> 
>> 
>> Ok. It was just an idea. Maybe something else will work, a "play" icon with 
>> a "page" or "print" icon. What is wise is that slightly different actions 
>> have slightly different icons.
>> 
>> Cheers,
>> 
>> Offray
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 

Re: [Pharo-users] mac address on windows

[p...@highoctane.be]

I've loaded your package.

A prerequisite is to load OS-Window to make it work.

I've got the DLL call working nicely and the nativeboost with the structure
freezing.

Now, we should all have a look at:

https://github.com/ronsaldo/bullet-pharo

and

https://github.com/ronsaldo/swig

because it looks like the way to go to wrap libraries...

Ronie, I know you modified swig for generating Pharo code;

Is cloning your swig repo the way to go ?


Phil




On Wed, May 6, 2015 at 10:39 AM, Usman Bhatti 
wrote:

> Hi Nicolai,
>
> Here is my package that defines the nativeboost call and associated C
> structs.
> The external C struct is self referencing and hence sometimes I get
> infinite recursion when trying to change field descriptions. That is the
> reason why the automatically generated accessors are absent (although I had
> them in an earlier version).
>
> Attached also the DLL referenced in the code.
>
>
>
> On Wed, May 6, 2015 at 9:58 AM, Nicolai Hess  wrote:
>
>>
>>
>> 2015-05-06 9:53 GMT+02:00 Usman Bhatti :
>>
>>>
>>>
>>> On Tue, May 5, 2015 at 7:34 PM, p...@highoctane.be 
>>> wrote:
>>>

 On Tue, May 5, 2015 at 6:28 PM, Usman Bhatti 
 wrote:

> I succeeded to do it by encapsulating the C routine as a DLL and doing
> an FFI call from my image (as suggested by Guille).
>

 At least there was a way!

>>>
>>> Exactly :)
>>>
>>>

 Looks like this is the most controlled|debuggable way:
   - get it working with C code out of Pharo
   - make a bridge that can be used easily with FFI in a dll
   - use that from Pharo with proven FFI

 Would NativeBoost work with your dll? Should.

>>>
>>> I have read a few resources about Nativeboost but I am still naive to
>>> know the difference between FFI and nativeboost. The FFI call I made to
>>> invoke the DLL function looked similar to the nativeboost calls.
>>>
>>>


 I also tried to perform the nativeboost call by creating my structures
> in Pharo. The function in Windows that can be used to retrieve mac address
> in Windows: GetAdaptersInfo
> 
>  that
> accepts a PIP_ADAPTER_INFO
> 
>  structure.
> I subclassed NBExternalStructure to define this struct and the other used
> by it in the image but my NB call returned with 87 code (Invalid 
> parameter)
> and it was impossible to debug. However, I would like to make this thing
> work to understand what went wrong.
>

 Has this something to do with 32|64 bit library complications?

>>>
>>> Not exactly. For me, it was more related to the fact that I had to map a
>>> complex C struct in Pharo. Here is an excerpt of the definition from MSDN:
>>>
>>> typedef struct _IP_ADAPTER_INFO {
>>>   struct _IP_ADAPTER_INFO  *Next;
>>>  ...
>>>   PIP_ADDR_STRING CurrentIpAddress;
>>>   IP_ADDR_STRING  GatewayList;
>>> ...
>>> }
>>>
>>> So, I had to define three external structures (all names in capitals)
>>> and I did the effort but in the end I got an error code that I could not
>>> debug in the image. Hence, I gave up and opted to go in the native
>>> environment. But I would like someone knowledgable to have a look at my
>>> nativeboost code  because the nativeboost approach is more simple
>>> (everything's in the image).
>>>
>>
>> I can have a look.
>>
>> btw. for what do you need the mac address?
>>
>>
>>
>>>
>>>
>>>
>>> usman
>>>
>>>

 Phil

>
> With ProcessWrapper, I could not load the classes essential for making
> the plugin work.
>
> HTH,
>
> Usman
>
>
>
>
> On Mon, May 4, 2015 at 2:54 PM, Ben Coman  wrote:
>
>> As a complete newb to VM building I found this fairly straight
>> forward (on a Mac btw).
>> https://github.com/pharo-project/pharo-vm
>> cheers -ben
>>
>> On Mon, May 4, 2015 at 5:28 PM, Usman Bhatti 
>> wrote:
>>
>>>
>>>
>>> On Sun, May 3, 2015 at 4:22 PM, Pierce Ng 
>>> wrote:
>>>
 On Sat, May 02, 2015 at 03:55:47PM +0200, Usman Bhatti wrote:
 > 1/ OSProcess: I tried  (PipeableOSProcess command: 'ipconfig
 /all') output.

 I have used http://www.smalltalkhub.com/#!/~hernan/ProcessWrapper
 successfully
 back when I was on Windows using some now-ancient version of Pharo.

>>>
>>> I had initially discarded the idea of using this project because it
>>> required a plugin and the information of the plugin was outdated on
>>> squeaksource. However, having evaluated superficially the complexity of
>>> doing it with nativeboost (because too many external c struct involved 
>>> in
>>> the call), I would like to see if I am better off using this wrapper.
>>>
>>> I loaded it with:
>

Re: [Pharo-users] Problems in switching from Moose 5.0 (Pharo 3) to Moose 5.1 (Pharo 4)

[PBKResearch]

Vincent

 

Many thanks. You have solved the problem and educated me in the process –
since I now know how to do a user interrupt – I was pressing Ctrl-Break with
no effect. The problem was the looping of the deprecation notifier, which I
can fix by removing the deprecated ‘value’ message. The looping should not
have occurred, and there must be a bug somewhere, but it’s not my problem.

 

One little detail, about your comment on point 6 below. On my system,
(TLTextTokenizer parse: 'test' startingAt: #word) generates an array of
PPToken, so it does not understand parsedValue. Are we looking at different
versions of TextLint?

 

Thanks again

 

Peter Kenny

 

From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of
Blondeau Vincent
Sent: 06 May 2015 10:00
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Problems in switching from Moose 5.0 (Pharo 3) to
Moose 5.1 (Pharo 4)

 

 

De : Pharo-users [ 
mailto:pharo-users-boun...@lists.pharo.org] De la part de PBKResearch
Envoyé : mardi 5 mai 2015 18:01
À :   pharo-users@lists.pharo.org
Objet : [Pharo-users] Problems in switching from Moose 5.0 (Pharo 3) to
Moose 5.1 (Pharo 4)

Hello,

 

I have been working with Moose 5.0 on a project involving natural language
processing. I used TextLint to parse the input, just because it contained a
set of parsers which gave output in a convenient form. I have read all about
the virtues of Pharo 4, and decided to give it a try, so I set out to
reproduce the earlier results. I have run into a number of problems –
basically I haven’t been able to get anywhere. I realise TextLint is rather
antique, but basically as I use it it is just a set of PetitParser parsers,
so I can’t see a problem.

 

I have boiled the problems down to a few test cases, not realistic bits of
my work but just to show the essential points.

 

1.  Environment: Windows 7 Professional (64 bit version).

2.  Download and install latest Pharo 4 - Latest update: #40612. This is
just to get an up to date VM.

3.  Download latest Moose 5.1 image and unzip into same folder as Pharo
4. On opening the Moose 5.1 image it also shows Latest update: #40612. (I
have to ignore Firefox’s hysterical warnings that the INRIA site does not
have a valid security certificate.)

4.  Load TextLint into the image. Can’t get ‘ConfigurationofTextLint’ to
work, so load TextLInt-Model-JorgeRessia.225.mcz and
TextLint-Tests-lr.166.mcz via the Monticello Browser. This is the same as I
used in my earlier Moose 5.0 image, where it worked as expected.

The ConfigurationofTextLint doesn’t not load because it can’t found the
project NEC which is not at 'http://ss3.gemstone.com/ss/NEC', it has to be
changed in ConfigurationOfGlamour>>default:.

Your configuration should not load Glamour because it is already included in
the Moose image. 

5.  Open a playground, enter:

PPToken on: ‘test’.

and select ‘Inspect it’. The inspector halts with message: ‘MNU
ByteString>>find AnySubstring:startingAt:’  Basic Inspect works as expected.
Does this look like the problem raised by Nicolas Lusa today?

Seems resolved on latest Moose5.1 (#874) on Pharo #40613.

6.  Enter in the playground:

word := (TLTextTokenizer parse: ‘test’ startingAt: #word) at: 1.

(The tokenizer gives an array of tokens, so we need to select the first –
and only – one.) Basic Inspect confirms that ‘word’ is a PPToken, as
expected.

The code doesn’t work, did you mean : (TLTextTokenizer parse: 'test'
startingAt: #word) parsedValue at: 1 ?

7.  Enter in the playground:

TLWord with: word.

Select ‘Do it’. The image becomes completely unresponsive, and appears to be
in a tight loop. Only way out is to click the Windows red X and say yes to
exit without saving. Restarting, get to the same point and select ‘Debug
it’. Trace it to TLSyntacticElement>>initializeWith: aToken, where the only
line of code is: ‘token := aToken’. Again a complete lockup.

Do ALT+. as soon you execute the method, you should be able to find the
error. By the way it seems that in TLSyntacticElement>>text, value has to be
replaced by inputValue (value is deprecated, and the notify event seems to
loop…). It seems to work after that.

 

Sorry for the lengthy details; I just hope there is enough there to enable
someone to diagnose the problem(s). Any help gratefully received. Meanwhile
I am back to the Pharo 3 version.

Clear details, though. I think you can go back to Pharo 4.

 

Thanks

You’re welcome,

 

Vincent Blondeau

 

Peter Kenny

 

 

 

  _  


Ce message et les pièces jointes sont confidentiels et réservés à l'usage
exclusif de ses destinataires. Il peut également être protégé par le secret
professionnel. Si vous recevez ce message par erreur, merci d'en avertir
immédiatement l'expéditeur et de le détruire. L'intégrité du message ne
pouvant être assurée sur Internet, la responsabilité de Worldline ne

Re: [Pharo-users] mac address on windows

[Nicolai Hess]

2015-05-06 12:10 GMT+02:00 p...@highoctane.be :

> I've loaded your package.
>
> A prerequisite is to load OS-Window to make it work.
>
> I've got the DLL call working nicely and the nativeboost with the
> structure freezing.
>

This is because you have a recursive datastructure description, but
acutually the IP_ADAPTER_INFO structure is not recursive:

PIP_ADAPTER_INFO class >>fieldsDex
^ #(
 PIP_ADAPTER_INFO  nextVariable;
  DWORD   ComboIndex;
  CHARAdapterName;
  CHARDescription;
)

The "nextVariable" should be a pointer to the structure.

from MSDN:

 struct _IP_ADAPTER_INFO {
  struct _IP_ADAPTER_INFO  *Next;   "<- pointer"
  DWORD   ComboIndex;
  charAdapterName[MAX_ADAPTER_NAME_LENGTH + 4];
  charDescription[MAX_ADAPTER_DESCRIPTION_LENGTH + 4];
  UINTAddressLength;












>
> Now, we should all have a look at:
>
> https://github.com/ronsaldo/bullet-pharo
>
> and
>
> https://github.com/ronsaldo/swig
>
> because it looks like the way to go to wrap libraries...
>
> Ronie, I know you modified swig for generating Pharo code;
>
> Is cloning your swig repo the way to go ?
>
>
> Phil
>
>
>
>
>
> On Wed, May 6, 2015 at 10:39 AM, Usman Bhatti 
> wrote:
>
>> Hi Nicolai,
>>
>> Here is my package that defines the nativeboost call and associated C
>> structs.
>> The external C struct is self referencing and hence sometimes I get
>> infinite recursion when trying to change field descriptions. That is the
>> reason why the automatically generated accessors are absent (although I had
>> them in an earlier version).
>>
>> Attached also the DLL referenced in the code.
>>
>>
>>
>> On Wed, May 6, 2015 at 9:58 AM, Nicolai Hess  wrote:
>>
>>>
>>>
>>> 2015-05-06 9:53 GMT+02:00 Usman Bhatti :
>>>


 On Tue, May 5, 2015 at 7:34 PM, p...@highoctane.be 
 wrote:

>
> On Tue, May 5, 2015 at 6:28 PM, Usman Bhatti 
> wrote:
>
>> I succeeded to do it by encapsulating the C routine as a DLL and
>> doing an FFI call from my image (as suggested by Guille).
>>
>
> At least there was a way!
>

 Exactly :)


>
> Looks like this is the most controlled|debuggable way:
>   - get it working with C code out of Pharo
>   - make a bridge that can be used easily with FFI in a dll
>   - use that from Pharo with proven FFI
>
> Would NativeBoost work with your dll? Should.
>

 I have read a few resources about Nativeboost but I am still naive to
 know the difference between FFI and nativeboost. The FFI call I made to
 invoke the DLL function looked similar to the nativeboost calls.


>
>
> I also tried to perform the nativeboost call by creating my structures
>> in Pharo. The function in Windows that can be used to retrieve mac 
>> address
>> in Windows: GetAdaptersInfo
>> 
>>  that
>> accepts a PIP_ADAPTER_INFO
>> 
>>  structure.
>> I subclassed NBExternalStructure to define this struct and the other used
>> by it in the image but my NB call returned with 87 code (Invalid 
>> parameter)
>> and it was impossible to debug. However, I would like to make this thing
>> work to understand what went wrong.
>>
>
> Has this something to do with 32|64 bit library complications?
>

 Not exactly. For me, it was more related to the fact that I had to map
 a complex C struct in Pharo. Here is an excerpt of the definition from 
 MSDN:

 typedef struct _IP_ADAPTER_INFO {
   struct _IP_ADAPTER_INFO  *Next;
  ...
   PIP_ADDR_STRING CurrentIpAddress;
   IP_ADDR_STRING  GatewayList;
 ...
 }

 So, I had to define three external structures (all names in capitals)
 and I did the effort but in the end I got an error code that I could not
 debug in the image. Hence, I gave up and opted to go in the native
 environment. But I would like someone knowledgable to have a look at my
 nativeboost code  because the nativeboost approach is more simple
 (everything's in the image).

>>>
>>> I can have a look.
>>>
>>> btw. for what do you need the mac address?
>>>
>>>
>>>



 usman


>
> Phil
>
>>
>> With ProcessWrapper, I could not load the classes essential for
>> making the plugin work.
>>
>> HTH,
>>
>> Usman
>>
>>
>>
>>
>> On Mon, May 4, 2015 at 2:54 PM, Ben Coman 
>> wrote:
>>
>>> As a complete newb to VM building I found this fairly straight
>>> forward (on a Mac btw).
>>> https://github.com/pharo-project/pharo-vm
>>> cheers -ben
>>>
>>> On Mon, M

Re: [Pharo-users] Woden-Roassal pharo5 inspector bugs

[Alexandre Bergel]

Apparently moose will soon move to Pharo 5. Maybe next week or so. 

Alexandre 



> Le 6 mai 2015 à 04:34, Lusa Nicolas  a écrit :
> 
> Hi,
> 
> thanks for the quick answer, I'll switch back to pharo4 for the moment.
> 
> Cheers,
> Nicolas
> 
> 

Re: [Pharo-users] mac address on windows

[Henrik Johansen]

> On 06 May 2015, at 12:29 , Nicolai Hess  wrote:
> 
> 
> 
> 2015-05-06 12:10 GMT+02:00 p...@highoctane.be  
> mailto:p...@highoctane.be>>:
> I've loaded your package.
> 
> A prerequisite is to load OS-Window to make it work.
> 
> I've got the DLL call working nicely and the nativeboost with the structure 
> freezing.
> 
> This is because you have a recursive datastructure description, but acutually 
> the IP_ADAPTER_INFO structure is not recursive:
> 
> PIP_ADAPTER_INFO class >>fieldsDex 
> ^ #(
>  PIP_ADAPTER_INFO  nextVariable;
>   DWORD   ComboIndex;
>   CHARAdapterName;
>   CHARDescription;
> )
> 
> The "nextVariable" should be a pointer to the structure.
> 
> from MSDN:
> 
>  struct _IP_ADAPTER_INFO {
>   struct _IP_ADAPTER_INFO  *Next;   "<- pointer"
>   DWORD   ComboIndex;
>   charAdapterName[MAX_ADAPTER_NAME_LENGTH + 4];
>   charDescription[MAX_ADAPTER_DESCRIPTION_LENGTH + 4];
>   UINTAddressLength;
> 
> 
> 

Also, the pOutBufLen parameter to GetAdaptorInfo is supposed to be a pointer to 
an unsigned long, holding the size of the buffer.
Setting that to an int in the NB declaration, will cause all sorts of trouble...

Cheers,
Henry

Re: [Pharo-users] mac address on windows

[p...@highoctane.be]

On Wed, May 6, 2015 at 12:29 PM, Nicolai Hess  wrote:

>
>
> 2015-05-06 12:10 GMT+02:00 p...@highoctane.be :
>
>> I've loaded your package.
>>
>> A prerequisite is to load OS-Window to make it work.
>>
>> I've got the DLL call working nicely and the nativeboost with the
>> structure freezing.
>>
>
> This is because you have a recursive datastructure description, but
> acutually the IP_ADAPTER_INFO structure is not recursive:
>
> PIP_ADAPTER_INFO class >>fieldsDex
> ^ #(
>  PIP_ADAPTER_INFO  nextVariable;
>   DWORD   ComboIndex;
>   CHARAdapterName;
>   CHARDescription;
> )
>
> The "nextVariable" should be a pointer to the structure.
>
> from MSDN:
>
>  struct _IP_ADAPTER_INFO {
>   struct _IP_ADAPTER_INFO  *Next;   "<- pointer"
>   DWORD   ComboIndex;
>   charAdapterName[MAX_ADAPTER_NAME_LENGTH + 4];
>   charDescription[MAX_ADAPTER_DESCRIPTION_LENGTH + 4];
>   UINTAddressLength;
>
> 
>
>
>

So, what's to put in there then?

I can use FFI / NB for basic cases but never ventured into those structure.
I'd like to :-)

Phil
I

>
>
>
>
>
>
>
>>
>> Now, we should all have a look at:
>>
>> https://github.com/ronsaldo/bullet-pharo
>>
>> and
>>
>> https://github.com/ronsaldo/swig
>>
>> because it looks like the way to go to wrap libraries...
>>
>> Ronie, I know you modified swig for generating Pharo code;
>>
>> Is cloning your swig repo the way to go ?
>>
>>
>> Phil
>>
>>
>>
>>
>>
>> On Wed, May 6, 2015 at 10:39 AM, Usman Bhatti 
>> wrote:
>>
>>> Hi Nicolai,
>>>
>>> Here is my package that defines the nativeboost call and associated C
>>> structs.
>>> The external C struct is self referencing and hence sometimes I get
>>> infinite recursion when trying to change field descriptions. That is the
>>> reason why the automatically generated accessors are absent (although I had
>>> them in an earlier version).
>>>
>>> Attached also the DLL referenced in the code.
>>>
>>>
>>>
>>> On Wed, May 6, 2015 at 9:58 AM, Nicolai Hess  wrote:
>>>


 2015-05-06 9:53 GMT+02:00 Usman Bhatti :

>
>
> On Tue, May 5, 2015 at 7:34 PM, p...@highoctane.be  > wrote:
>
>>
>> On Tue, May 5, 2015 at 6:28 PM, Usman Bhatti 
>> wrote:
>>
>>> I succeeded to do it by encapsulating the C routine as a DLL and
>>> doing an FFI call from my image (as suggested by Guille).
>>>
>>
>> At least there was a way!
>>
>
> Exactly :)
>
>
>>
>> Looks like this is the most controlled|debuggable way:
>>   - get it working with C code out of Pharo
>>   - make a bridge that can be used easily with FFI in a dll
>>   - use that from Pharo with proven FFI
>>
>> Would NativeBoost work with your dll? Should.
>>
>
> I have read a few resources about Nativeboost but I am still naive to
> know the difference between FFI and nativeboost. The FFI call I made to
> invoke the DLL function looked similar to the nativeboost calls.
>
>
>>
>>
>> I also tried to perform the nativeboost call by creating my
>>> structures in Pharo. The function in Windows that can be used to 
>>> retrieve
>>> mac address in Windows: GetAdaptersInfo
>>> 
>>>  that
>>> accepts a PIP_ADAPTER_INFO
>>> 
>>>  structure.
>>> I subclassed NBExternalStructure to define this struct and the other 
>>> used
>>> by it in the image but my NB call returned with 87 code (Invalid 
>>> parameter)
>>> and it was impossible to debug. However, I would like to make this thing
>>> work to understand what went wrong.
>>>
>>
>> Has this something to do with 32|64 bit library complications?
>>
>
> Not exactly. For me, it was more related to the fact that I had to map
> a complex C struct in Pharo. Here is an excerpt of the definition from 
> MSDN:
>
> typedef struct _IP_ADAPTER_INFO {
>   struct _IP_ADAPTER_INFO  *Next;
>  ...
>   PIP_ADDR_STRING CurrentIpAddress;
>   IP_ADDR_STRING  GatewayList;
> ...
> }
>
> So, I had to define three external structures (all names in capitals)
> and I did the effort but in the end I got an error code that I could not
> debug in the image. Hence, I gave up and opted to go in the native
> environment. But I would like someone knowledgable to have a look at my
> nativeboost code  because the nativeboost approach is more simple
> (everything's in the image).
>

 I can have a look.

 btw. for what do you need the mac address?



>
>
>
> usman
>
>
>>
>> Phil
>>
>>>
>>> With ProcessWrapper, I could n

[Pharo-users] Halo Menu On Spec Tree Node

[Craig Johnson]

Hi All,

I had an issue - when I opened a Halo on a Spec tree node in the UI and 
select the menu Icon, I got a DNU message.  However if I selected a 
normal Morph, the menu Icon worked fine.


I'm using Pharo 4.0 released version.

Fixed this by changing TreeModel>>iconFor to:
iconFor: aNode
^ iconBlock value cull: aNode content*s* cull: aNode



Craig

Re: [Pharo-users] Problems in switching from Moose 5.0 (Pharo 3) to Moose 5.1 (Pharo 4)

[Blondeau Vincent]

De : Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] De la part de 
PBKResearch
Envoyé : mercredi 6 mai 2015 12:12
À : 'Any question about pharo is welcome'
Objet : Re: [Pharo-users] Problems in switching from Moose 5.0 (Pharo 3) to 
Moose 5.1 (Pharo 4)

Vincent
Peter,
Many thanks. You have solved the problem and educated me in the process - since 
I now know how to do a user interrupt - I was pressing Ctrl-Break with no 
effect. The problem was the looping of the deprecation notifier, which I can 
fix by removing the deprecated 'value' message. The looping should not have 
occurred, and there must be a bug somewhere, but it's not my problem.
Actually, the notify message open a debugger and "value" message is send by the 
debugger, but value send a notify message that opens a new debugger...  etc... 
I don't think that is a bug. It is not the notify: method that should be used 
but the deprecated: one.

One little detail, about your comment on point 6 below. On my system, 
(TLTextTokenizer parse: 'test' startingAt: #word) generates an array of 
PPToken, so it does not understand parsedValue. Are we looking at different 
versions of TextLint?
TLTextTokenizer parse: 'test' startingAt: #word return a PPToken, not an array 
on PPToken in the version I have.
I have this version of TextLint :
Name: TextLint-Model-JorgeRessia.225
Author: JorgeRessia
Time: 10 February 2012, 2:41:11 pm
UUID: 3c6965a4-bc1f-42e4-b309-fab8e4303046
Ancestors: TextLint-Model-lr.224

Name: TextLint-Tests-lr.166
Author: lr
Time: 25 March 2012, 10:46:49 am
UUID: ed387b31-02e6-4194-91e6-18d3879dc858
Ancestors: TextLint-Tests-DamienCassou.165

And petit parser:
Name: PetitParser-JanKurs.278
Author: JanKurs
Time: 5 May 2015, 2:39:26.475846 pm
UUID: 55ae813a-5dfd-4b4d-a98b-274f5431331e
Ancestors: PetitParser-JanKurs.277, PetitParser-JanKurs.276

Vincent Blondeau

Thanks again

Peter Kenny

From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
Blondeau Vincent
Sent: 06 May 2015 10:00
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Problems in switching from Moose 5.0 (Pharo 3) to 
Moose 5.1 (Pharo 4)


De : Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] De la part de 
PBKResearch
Envoyé : mardi 5 mai 2015 18:01
À : pharo-users@lists.pharo.org
Objet : [Pharo-users] Problems in switching from Moose 5.0 (Pharo 3) to Moose 
5.1 (Pharo 4)
Hello,

I have been working with Moose 5.0 on a project involving natural language 
processing. I used TextLint to parse the input, just because it contained a set 
of parsers which gave output in a convenient form. I have read all about the 
virtues of Pharo 4, and decided to give it a try, so I set out to reproduce the 
earlier results. I have run into a number of problems - basically I haven't 
been able to get anywhere. I realise TextLint is rather antique, but basically 
as I use it it is just a set of PetitParser parsers, so I can't see a problem.

I have boiled the problems down to a few test cases, not realistic bits of my 
work but just to show the essential points.


1.  Environment: Windows 7 Professional (64 bit version).

2.  Download and install latest Pharo 4 - Latest update: #40612. This is 
just to get an up to date VM.

3.  Download latest Moose 5.1 image and unzip into same folder as Pharo 4. 
On opening the Moose 5.1 image it also shows Latest update: #40612. (I have to 
ignore Firefox's hysterical warnings that the INRIA site does not have a valid 
security certificate.)

4.  Load TextLint into the image. Can't get 'ConfigurationofTextLint' to 
work, so load TextLInt-Model-JorgeRessia.225.mcz and TextLint-Tests-lr.166.mcz 
via the Monticello Browser. This is the same as I used in my earlier Moose 5.0 
image, where it worked as expected.

The ConfigurationofTextLint doesn't not load because it can't found the project 
NEC which is not at 'http://ss3.gemstone.com/ss/NEC', it has to be changed in 
ConfigurationOfGlamour>>default:.

Your configuration should not load Glamour because it is already included in 
the Moose image.

5.  Open a playground, enter:

PPToken on: 'test'.

and select 'Inspect it'. The inspector halts with message: 'MNU 
ByteString>>find AnySubstring:startingAt:'  Basic Inspect works as expected. 
Does this look like the problem raised by Nicolas Lusa today?

Seems resolved on latest Moose5.1 (#874) on Pharo #40613.

6.  Enter in the playground:

word := (TLTextTokenizer parse: 'test' startingAt: #word) at: 1.

(The tokenizer gives an array of tokens, so we need to select the first - and 
only - one.) Basic Inspect confirms that 'word' is a PPToken, as expected.

The code doesn't work, did you mean : (TLTextTokenizer parse: 'test' 
startingAt: #word) parsedValue at: 1 ?

7.  Enter in the playground:

TLWord with: word.

Select 'Do it'. The image becomes completely unresponsive, and appears to be in 
a tight loop. Only way out is to click the Windows red

Re: [Pharo-users] A Pharo..

[Hilaire]

And the making-of, in French but you can still view the movie :)
It is really for young kids.

https://plus.google.com/+DrgeoEu/posts/Q8xokLpkXFM

Le 05/05/2015 18:55, Hilaire a écrit :
> With Dr. Geo
>


-- 
Dr. Geo
http://drgeo.eu
http://google.com/+DrgeoEu

Re: [Pharo-users] mac address on windows

[Esteban Lorenzano]

> On 06 May 2015, at 12:10, p...@highoctane.be wrote:
> 
> I've loaded your package.
> 
> A prerequisite is to load OS-Window to make it work.

why?
in any case, oswindow is already included in pharo4

Esteban

> 
> I've got the DLL call working nicely and the nativeboost with the structure 
> freezing.
> 
> Now, we should all have a look at:
> 
> https://github.com/ronsaldo/bullet-pharo 
> 
> 
> and
> 
> https://github.com/ronsaldo/swig 
> 
> because it looks like the way to go to wrap libraries...
> 
> Ronie, I know you modified swig for generating Pharo code;
> 
> Is cloning your swig repo the way to go ?
> 
> 
> Phil
> 
> 
> 
> 
> On Wed, May 6, 2015 at 10:39 AM, Usman Bhatti  > wrote:
> Hi Nicolai,
> 
> Here is my package that defines the nativeboost call and associated C structs.
> The external C struct is self referencing and hence sometimes I get infinite 
> recursion when trying to change field descriptions. That is the reason why 
> the automatically generated accessors are absent (although I had them in an 
> earlier version).
> 
> Attached also the DLL referenced in the code.
> 
> 
> 
> On Wed, May 6, 2015 at 9:58 AM, Nicolai Hess  > wrote:
> 
> 
> 2015-05-06 9:53 GMT+02:00 Usman Bhatti  >:
> 
> 
> On Tue, May 5, 2015 at 7:34 PM, p...@highoctane.be 
>  mailto:p...@highoctane.be>> 
> wrote:
> 
> On Tue, May 5, 2015 at 6:28 PM, Usman Bhatti  > wrote:
> I succeeded to do it by encapsulating the C routine as a DLL and doing an FFI 
> call from my image (as suggested by Guille).
> 
> At least there was a way! 
> 
> Exactly :)
>  
> 
> Looks like this is the most controlled|debuggable way:
>   - get it working with C code out of Pharo
>   - make a bridge that can be used easily with FFI in a dll
>   - use that from Pharo with proven FFI
> 
> Would NativeBoost work with your dll? Should.
> 
> I have read a few resources about Nativeboost but I am still naive to know 
> the difference between FFI and nativeboost. The FFI call I made to invoke the 
> DLL function looked similar to the nativeboost calls.
>  
> 
> 
> I also tried to perform the nativeboost call by creating my structures in 
> Pharo. The function in Windows that can be used to retrieve mac address in 
> Windows: GetAdaptersInfo 
> 
>  that accepts a PIP_ADAPTER_INFO  
> 
>  structure. I subclassed NBExternalStructure to define this struct and the 
> other used by it in the image but my NB call returned with 87 code (Invalid 
> parameter) and it was impossible to debug. However, I would like to make this 
> thing work to understand what went wrong.
> 
> Has this something to do with 32|64 bit library complications? 
> 
> Not exactly. For me, it was more related to the fact that I had to map a 
> complex C struct in Pharo. Here is an excerpt of the definition from MSDN:
> 
> typedef struct _IP_ADAPTER_INFO {
>   struct _IP_ADAPTER_INFO  *Next;
>  ...
> PIP_ADDR_STRING CurrentIpAddress;
>   IP_ADDR_STRING  GatewayList;
>   ...
> }
> 
> So, I had to define three external structures (all names in capitals) and I 
> did the effort but in the end I got an error code that I could not debug in 
> the image. Hence, I gave up and opted to go in the native environment. But I 
> would like someone knowledgable to have a look at my nativeboost code  
> because the nativeboost approach is more simple (everything's in the image).
> 
> I can have a look.
> 
> btw. for what do you need the mac address?
> 
>  
> 
> 
> 
> usman
>  
> 
> Phil
> 
> With ProcessWrapper, I could not load the classes essential for making the 
> plugin work.
> 
> HTH,
> 
> Usman
> 
> 
> 
> 
> On Mon, May 4, 2015 at 2:54 PM, Ben Coman  > wrote:
> As a complete newb to VM building I found this fairly straight forward (on a 
> Mac btw).
> https://github.com/pharo-project/pharo-vm 
> 
> cheers -ben
> 
> On Mon, May 4, 2015 at 5:28 PM, Usman Bhatti  > wrote:
> 
> 
> On Sun, May 3, 2015 at 4:22 PM, Pierce Ng  > wrote:
> On Sat, May 02, 2015 at 03:55:47PM +0200, Usman Bhatti wrote:
> > 1/ OSProcess: I tried  (PipeableOSProcess command: 'ipconfig /all') output.
> 
> I have used http://www.smalltalkhub.com/#!/~hernan/ProcessWrapper 
>  successfully
> back when I was on Windows using some now-ancient version of Pharo.
> 
> I had initially discarded the idea of using this project because it required 
> a plugin and the information of the plugin was outdated on squeaksource. 
> However, havi

Re: [Pharo-users] WebSocket and Proxying ...

[itli...@schrievkrom.de]

Hmm, at least I managed, that Pharo answered every second request using
the echo example

Under Windows and nginx I added to the nginx configuration. My local
Pharo server is running under 127.0.0.1:4:

extract from nginx.conf:

http:{

map $http_upgrade $connection_upgrade {
default upgrade;
}

server {

 location /ws-echo {
   proxy_pass http://127.0.0.1:4/ws-echo ;
   proxy_http_version 1.1;
   proxy_set_header Upgrade $http_upgrade;
   proxy_set_header Connection $connection_upgrade;
 }
 location /ws-echo-client {
   proxy_pass http://127.0.0.1:4/ws-echo-client ;
 }

 }
}



Am 06.05.2015 um 10:20 schrieb Sven Van Caekenberghe:
> Marten,
> 
>> On 06 May 2015, at 10:15, itli...@schrievkrom.de wrote:
>>
>> Hello,
>>
>> I'm playing with WebSockets under Pharo4 and this works as expected -
>> when using Pharo4 alone (using the Zinc packages).
>>
>> But I did not get it to work, when e.g. doing a proxying via nginx (I
>> did not check it with Apache).
>>
>> Actually Pharo4 seems to receive some stuff, because the WebSocket of
>> Pharo4 stuff does not work as expected after first proxying attempts.
>>
>> Has anyone experience with that ?
>>
>> Marten
> 
> Proxying the WebSockets protocol is not easy, nor implemented everywhere, 
> like HTTP is. This makes sense if you think about it, a WebSocket connection 
> is a permanent connection, which takes resources, this is not something most 
> servers like.
> 
> So it is more difficult.
> 
> Did you see/try http://nginx.org/en/docs/http/websocket.html ?
> 
> (I did not try it)
> 
> Sven
> 
> 


-- 
Marten Feldtmann

Re: [Pharo-users] mac address on windows

[Nicolai Hess]

2015-05-06 16:40 GMT+02:00 Esteban Lorenzano :

>
> On 06 May 2015, at 12:10, p...@highoctane.be wrote:
>
> I've loaded your package.
>
> A prerequisite is to load OS-Window to make it work.
>
>
> why?
> in any case, oswindow is already included in pharo4
>

OS-Windows (by TorstenBergmann)
not
OSWindow  :)

It is needed for the shared pool WinTypes,
but without OS-Window, he can use NBWinTypes instead.



>
> Esteban
>
>
> I've got the DLL call working nicely and the nativeboost with the
> structure freezing.
>
> Now, we should all have a look at:
>
> https://github.com/ronsaldo/bullet-pharo
>
> and
>
> https://github.com/ronsaldo/swig
>
> because it looks like the way to go to wrap libraries...
>
> Ronie, I know you modified swig for generating Pharo code;
>
> Is cloning your swig repo the way to go ?
>
>
> Phil
>
>
>
>
> On Wed, May 6, 2015 at 10:39 AM, Usman Bhatti 
> wrote:
>
>> Hi Nicolai,
>>
>> Here is my package that defines the nativeboost call and associated C
>> structs.
>> The external C struct is self referencing and hence sometimes I get
>> infinite recursion when trying to change field descriptions. That is the
>> reason why the automatically generated accessors are absent (although I had
>> them in an earlier version).
>>
>> Attached also the DLL referenced in the code.
>>
>>
>>
>> On Wed, May 6, 2015 at 9:58 AM, Nicolai Hess  wrote:
>>
>>>
>>>
>>> 2015-05-06 9:53 GMT+02:00 Usman Bhatti :
>>>


 On Tue, May 5, 2015 at 7:34 PM, p...@highoctane.be 
 wrote:

>
> On Tue, May 5, 2015 at 6:28 PM, Usman Bhatti 
> wrote:
>
>> I succeeded to do it by encapsulating the C routine as a DLL and
>> doing an FFI call from my image (as suggested by Guille).
>>
>
> At least there was a way!
>

 Exactly :)


>
> Looks like this is the most controlled|debuggable way:
>   - get it working with C code out of Pharo
>   - make a bridge that can be used easily with FFI in a dll
>   - use that from Pharo with proven FFI
>
> Would NativeBoost work with your dll? Should.
>

 I have read a few resources about Nativeboost but I am still naive to
 know the difference between FFI and nativeboost. The FFI call I made to
 invoke the DLL function looked similar to the nativeboost calls.


>
>
> I also tried to perform the nativeboost call by creating my structures
>> in Pharo. The function in Windows that can be used to retrieve mac 
>> address
>> in Windows: GetAdaptersInfo
>> 
>>  that
>> accepts a PIP_ADAPTER_INFO
>> 
>>  structure.
>> I subclassed NBExternalStructure to define this struct and the other used
>> by it in the image but my NB call returned with 87 code (Invalid 
>> parameter)
>> and it was impossible to debug. However, I would like to make this thing
>> work to understand what went wrong.
>>
>
> Has this something to do with 32|64 bit library complications?
>

 Not exactly. For me, it was more related to the fact that I had to map
 a complex C struct in Pharo. Here is an excerpt of the definition from 
 MSDN:

 typedef struct _IP_ADAPTER_INFO {
   struct _IP_ADAPTER_INFO  *Next;
  ...
   PIP_ADDR_STRING CurrentIpAddress;
   IP_ADDR_STRING  GatewayList;
 ...
 }

 So, I had to define three external structures (all names in capitals)
 and I did the effort but in the end I got an error code that I could not
 debug in the image. Hence, I gave up and opted to go in the native
 environment. But I would like someone knowledgable to have a look at my
 nativeboost code  because the nativeboost approach is more simple
 (everything's in the image).

>>>
>>> I can have a look.
>>>
>>> btw. for what do you need the mac address?
>>>
>>>
>>>



 usman


>
> Phil
>
> With ProcessWrapper, I could not load the classes essential for making
> the plugin work.
>
> HTH,
>
> Usman
>
>
>
>
> On Mon, May 4, 2015 at 2:54 PM, Ben Coman  wrote:
> As a complete newb to VM building I found this fairly straight forward
> (on a Mac btw).
> https://github.com/pharo-project/pharo-vm
> cheers -ben
>
> On Mon, May 4, 2015 at 5:28 PM, Usman Bhatti 
> wrote:
>
>
> On Sun, May 3, 2015 at 4:22 PM, Pierce Ng 
> wrote:
> On Sat, May 02, 2015 at 03:55:47PM +0200, Usman Bhatti wrote:
> > 1/ OSProcess: I tried  (PipeableOSProcess command: 'ipconfig /all')
> output.
>
> I have used http://www.smalltalkhub.com/#!/~hernan/ProcessWrapper
> successfully
> back when I was on Windows using some now-ancient version of Pharo.
>
> I 

[Pharo-users] Some Athens modifications ?

[Matthieu Lacaton]

Hello everybody,

I was playing arround with Athens lately and I think I encountered a few
small bugs along the way (I may be wrong though) :

1) In *LinearGradientPaint class >> from:* aStartPoint *to:* aStopPoint
There is a call to the method *"initializeFrom: aStartPoint to: aStopPoint"*
but this method does not exist. I think the whole method could probably be
replaced by :

*LinearGradientPaint class >>* *from:* aStartPoint *to:* aStopPoint
  ^ self new start: aStartPoint; stop: aStopPoint; yourself.

2) This is not much but in the *GradientPaint* class there is an instance
variable named *"stops"* but it seems that it is never used.

3) In AthensCairoMatrix there is a difference in the variable order
between *AthensCairoMatrix
class >> fieldsDesc* and *AthensCairoMatrix >> initx: y: sx: sy: shx: shy:*

In the first one the order is "sx, shx, shy, sy, x, y" whereas in the
second one it is "sx, shy, shx, sy, x, y". However, according to the
cairoGraphics API documentation, the order should be the same.

By the way I have a small question : Why not keep the same variable names
than in cairoGraphics here (xx, yx, xy, yy, x0, y0) ?

4) In *AthensCairoMatrix >> primMultiplyBy:* m.

The function as defined in C is the following :

void
cairo_matrix_multiply (*cairo_matrix_t

*result*,
   *const cairo_matrix_t

*a*,
   *const cairo_matrix_t

*b*);

It is stated that

*"The effect of the resulting transformation is to first apply the
transformation in a to the coordinates and then apply the transformation in
b to the coordinates."*
In Pharo it is defined like this :





*void   cairo_matrix_multiply (  AthensCairoMatrix * self,
   AthensCairoMatrix * m ,
  AthensCairoMatrix * self )*
For me, when writing "self multiplyBy: aRotationTransformation" it seems
more logical to first do the self transformation" and then the rotation
transformation (especially if we want a cascade of transformations).
However, as currently written in Pharo it is actually the rotation
transformation that is applied and then the self transformation.

For example, if I want a scaling then a rotation then a translation it
seems easier to me to do :
myTransformation := myTransformation multiplyBy: scalingTransformation.
myTransformation := myTransformation multiplyBy: rotationTransformation.
myTransformation := myTransformation multiplyBy: translationTransformation.
etc. if I want some other transformations.

So it could be nice to have a



*a method defined like this : void   cairo_matrix_multiply (
AthensCairoMatrix * self,
AthensCairoMatrix * self ,
AthensCairoMatrix * m )*


What do you think about it ?

Thanks,

Matthieu

Re: [Pharo-users] mac address on windows

[Esteban Lorenzano]

> On 06 May 2015, at 17:03, Nicolai Hess  wrote:
> 
> 
> 
> 2015-05-06 16:40 GMT+02:00 Esteban Lorenzano  >:
> 
>> On 06 May 2015, at 12:10, p...@highoctane.be  
>> wrote:
>> 
>> I've loaded your package.
>> 
>> A prerequisite is to load OS-Window to make it work.
> 
> why?
> in any case, oswindow is already included in pharo4
> 
> OS-Windows (by TorstenBergmann)
> not
> OSWindow  :)

ahhh. Name clash :)

> 
> It is needed for the shared pool WinTypes, 
> but without OS-Window, he can use NBWinTypes instead.
> 
>  
> 
> Esteban
> 
>> 
>> I've got the DLL call working nicely and the nativeboost with the structure 
>> freezing.
>> 
>> Now, we should all have a look at:
>> 
>> https://github.com/ronsaldo/bullet-pharo 
>> 
>> 
>> and
>> 
>> https://github.com/ronsaldo/swig 
>> 
>> because it looks like the way to go to wrap libraries...
>> 
>> Ronie, I know you modified swig for generating Pharo code;
>> 
>> Is cloning your swig repo the way to go ?
>> 
>> 
>> Phil
>> 
>> 
>> 
>> 
>> On Wed, May 6, 2015 at 10:39 AM, Usman Bhatti > > wrote:
>> Hi Nicolai,
>> 
>> Here is my package that defines the nativeboost call and associated C 
>> structs.
>> The external C struct is self referencing and hence sometimes I get infinite 
>> recursion when trying to change field descriptions. That is the reason why 
>> the automatically generated accessors are absent (although I had them in an 
>> earlier version).
>> 
>> Attached also the DLL referenced in the code.
>> 
>> 
>> 
>> On Wed, May 6, 2015 at 9:58 AM, Nicolai Hess > > wrote:
>> 
>> 
>> 2015-05-06 9:53 GMT+02:00 Usman Bhatti > >:
>> 
>> 
>> On Tue, May 5, 2015 at 7:34 PM, p...@highoctane.be 
>>  mailto:p...@highoctane.be>> 
>> wrote:
>> 
>> On Tue, May 5, 2015 at 6:28 PM, Usman Bhatti > > wrote:
>> I succeeded to do it by encapsulating the C routine as a DLL and doing an 
>> FFI call from my image (as suggested by Guille).
>> 
>> At least there was a way! 
>> 
>> Exactly :)
>>  
>> 
>> Looks like this is the most controlled|debuggable way:
>>   - get it working with C code out of Pharo
>>   - make a bridge that can be used easily with FFI in a dll
>>   - use that from Pharo with proven FFI
>> 
>> Would NativeBoost work with your dll? Should.
>> 
>> I have read a few resources about Nativeboost but I am still naive to know 
>> the difference between FFI and nativeboost. The FFI call I made to invoke 
>> the DLL function looked similar to the nativeboost calls.
>>  
>> 
>> 
>> I also tried to perform the nativeboost call by creating my structures in 
>> Pharo. The function in Windows that can be used to retrieve mac address in 
>> Windows: GetAdaptersInfo 
>> 
>>  that accepts a PIP_ADAPTER_INFO  
>> 
>>  structure. I subclassed NBExternalStructure to define this struct and the 
>> other used by it in the image but my NB call returned with 87 code (Invalid 
>> parameter) and it was impossible to debug. However, I would like to make 
>> this thing work to understand what went wrong.
>> 
>> Has this something to do with 32|64 bit library complications? 
>> 
>> Not exactly. For me, it was more related to the fact that I had to map a 
>> complex C struct in Pharo. Here is an excerpt of the definition from MSDN:
>> 
>> typedef struct _IP_ADAPTER_INFO {
>>   struct _IP_ADAPTER_INFO  *Next;
>>  ...
>>PIP_ADDR_STRING CurrentIpAddress;
>>   IP_ADDR_STRING  GatewayList;
>>  ...
>> }
>> 
>> So, I had to define three external structures (all names in capitals) and I 
>> did the effort but in the end I got an error code that I could not debug in 
>> the image. Hence, I gave up and opted to go in the native environment. But I 
>> would like someone knowledgable to have a look at my nativeboost code  
>> because the nativeboost approach is more simple (everything's in the image).
>> 
>> I can have a look.
>> 
>> btw. for what do you need the mac address?
>> 
>>  
>> 
>> 
>> 
>> usman
>>  
>> 
>> Phil
>> 
>> With ProcessWrapper, I could not load the classes essential for making the 
>> plugin work.
>> 
>> HTH,
>> 
>> Usman
>> 
>> 
>> 
>> 
>> On Mon, May 4, 2015 at 2:54 PM, Ben Coman > > wrote:
>> As a complete newb to VM building I found this fairly straight forward (on a 
>> Mac btw).
>> https://github.com/pharo-project/pharo-vm 
>> 
>> cheers -ben
>> 
>> On Mon, May 4, 2015 at 5:28 PM, Usman Bhatti > > wrote:
>> 
>> 
>> On Sun, May 3, 2015 at 4:22 PM, Pierce Ng > > wrote:
>> On S

[Pharo-users] MouseWheel events

[Matthieu Lacaton]

Hello everyone,

I have a question about MouseWheel events in Pharo.

On Linux, when I use the wheel of my mouse the event I get in return is an
instance of MouseWheelEvent :
*" [(606@633) mouseWheel Character arrowDown CTRL 33261828 nil] "*

When I press "CTRL + ArrowUp" or "CTRL + ArrowDown" on my keyboard I get
the same type of MouseWheelEvent.

On the other side, on Windows XP, when I press "CTRL + ArrowUp" or "CTRL +
ArrowDown" on my keyboard I also get a MouseWheelEvent but when I use the
wheel of my mouse I get a Keystroke event :
*" [keystroke ''] "* with a keyValue of 30 for a mousewheel up and
31 for a mousewheel down.

I am a bit confused about this :

Shouldn't I get a MouseWheel event when i use the wheel and a keystroke
when I use CTRL + Arrow ?

Why is it different from Linux to Windows ?

In both cases I used Pharo4 VM + a fresh pharo 4 image.

Thanks,

Matthieu

Re: [Pharo-users] [ANN] Idea icon pack now in Configuration Browser

[Offray Vladimir Luna Cárdenas]

Hi,

El 05/05/15 a las 11:34, Esteban Lorenzano escribió:



On 05 May 2015, at 17:59, Offray Vladimir Luna Cárdenas  
wrote:

Hi,

El 04/05/15 a las 18:05, Esteban Lorenzano escribió:



On 05 May 2015, at 01:10, Offray Vladimir Luna Cárdenas mailto:off...@riseup.net>> wrote:

May be the small icon of the glasses works better now that the print preview
is not "polluting" the writing of code, but has a tooltip with glasses on it.


no, because that’s the icon for “inspect” and what you see there is is
playground specific: is showing the result and offering you the possibility of
inspect it, yet the glasses.

Esteban



Ok. It was just an idea. Maybe something else will work, a "play" icon with a "page" or 
"print" icon. What is wise is that slightly different actions have slightly different icons.


yes, but that means I need to take pixelimator and create an icon.
A painful and not really compensating task.
I can try it, with time (it is in my todo).
but it will happen when it happens :)

Esteban




Fine :). Surely creating icons by hand is not the proper solution. Idea 
icons are a nice improvement and when they get better and we have more 
icons and themes surely we will have a more broad repertory to choose from.


Cheers,

Offray

Re: [Pharo-users] WebSocket and Proxying ...

[itli...@schrievkrom.de]

Ok, I managed to make it work somehow:

I removed the static file serving from Pharo and put the
"ws-echo-client" code to the file system and it is now handled by nginx.

Now only WebSocket stuff is done by Pharo and this seems to work without
problems.

That means: the mixture of static-stuff and websocket handling breaks
the system: browser (Firefox or Chrome or IE11) <-> nginx <-> Pharo

Not the solution I wanted, but at least a way to make WebSockets working
under Pharo ...

Marten



Am 06.05.2015 um 16:48 schrieb itli...@schrievkrom.de:
> Hmm, at least I managed, that Pharo answered every second request using
> the echo example
> 
> Under Windows and nginx I added to the nginx configuration. My local
> Pharo server is running under 127.0.0.1:4:
> 
> extract from nginx.conf:
> 
> http:{
> 
> map $http_upgrade $connection_upgrade {
> default upgrade;
> }
> 
> server {
> 
>  location /ws-echo {
>proxy_pass http://127.0.0.1:4/ws-echo ;
>proxy_http_version 1.1;
>proxy_set_header Upgrade $http_upgrade;
>proxy_set_header Connection $connection_upgrade;
>  }
>  location /ws-echo-client {
>proxy_pass http://127.0.0.1:4/ws-echo-client ;
>  }
> 
>  }
> }
> 
> 
> 
> Am 06.05.2015 um 10:20 schrieb Sven Van Caekenberghe:
>> Marten,
>>
>>> On 06 May 2015, at 10:15, itli...@schrievkrom.de wrote:
>>>
>>> Hello,
>>>
>>> I'm playing with WebSockets under Pharo4 and this works as expected -
>>> when using Pharo4 alone (using the Zinc packages).
>>>
>>> But I did not get it to work, when e.g. doing a proxying via nginx (I
>>> did not check it with Apache).
>>>
>>> Actually Pharo4 seems to receive some stuff, because the WebSocket of
>>> Pharo4 stuff does not work as expected after first proxying attempts.
>>>
>>> Has anyone experience with that ?
>>>
>>> Marten
>>
>> Proxying the WebSockets protocol is not easy, nor implemented everywhere, 
>> like HTTP is. This makes sense if you think about it, a WebSocket connection 
>> is a permanent connection, which takes resources, this is not something most 
>> servers like.
>>
>> So it is more difficult.
>>
>> Did you see/try http://nginx.org/en/docs/http/websocket.html ?
>>
>> (I did not try it)
>>
>> Sven
>>
>>
> 
> 


-- 
Marten Feldtmann

Re: [Pharo-users] Halo Menu On Spec Tree Node

[Nicolai Hess]

2015-05-06 13:47 GMT+02:00 Craig Johnson :

>  Hi All,
>
> I had an issue - when I opened a Halo on a Spec tree node in the UI and
> select the menu Icon, I got a DNU message.  However if I selected a normal
> Morph, the menu Icon worked fine.
>
> I'm using Pharo 4.0 released version.
>
> Fixed this by changing TreeModel>>iconFor to:
> iconFor: aNode
> ^ iconBlock value cull: aNode content*s* cull: aNode
>
>
Hi,

Thank you for the report (and the fix)
I made a bugtracker entry:

15500 
SpecTreeNodeModel(Object)>>doesNotUnderstand: #content




>
>
> Craig
>
>
>

Re: [Pharo-users] Halo Menu On Spec Tree Node

[Sergio Fedi]

Thanks for making the new case, I may resolve it soon.​

Re: [Pharo-users] WebSocket and Proxying ...

[Sven Van Caekenberghe]

Good that it works now, maybe your problem is that /ws-echo comes before and 
maybe also matches /ws-echo-client ? But I am no nginx expert.

Maybe you try serving and proxying it as /client-ws-echo ? Or switch the order ?

> On 06 May 2015, at 20:11, itli...@schrievkrom.de wrote:
> 
> Ok, I managed to make it work somehow:
> 
> I removed the static file serving from Pharo and put the
> "ws-echo-client" code to the file system and it is now handled by nginx.
> 
> Now only WebSocket stuff is done by Pharo and this seems to work without
> problems.
> 
> That means: the mixture of static-stuff and websocket handling breaks
> the system: browser (Firefox or Chrome or IE11) <-> nginx <-> Pharo
> 
> Not the solution I wanted, but at least a way to make WebSockets working
> under Pharo ...
> 
> Marten
> 
> 
> 
> Am 06.05.2015 um 16:48 schrieb itli...@schrievkrom.de:
>> Hmm, at least I managed, that Pharo answered every second request using
>> the echo example
>> 
>> Under Windows and nginx I added to the nginx configuration. My local
>> Pharo server is running under 127.0.0.1:4:
>> 
>> extract from nginx.conf:
>> 
>> http:{
>> 
>>map $http_upgrade $connection_upgrade {
>>default upgrade;
>>}
>> 
>> server {
>> 
>> location /ws-echo {
>>   proxy_pass http://127.0.0.1:4/ws-echo ;
>>   proxy_http_version 1.1;
>>   proxy_set_header Upgrade $http_upgrade;
>>   proxy_set_header Connection $connection_upgrade;
>> }
>> location /ws-echo-client {
>>   proxy_pass http://127.0.0.1:4/ws-echo-client ;
>> }
>> 
>> }
>> }
>> 
>> 
>> 
>> Am 06.05.2015 um 10:20 schrieb Sven Van Caekenberghe:
>>> Marten,
>>> 
 On 06 May 2015, at 10:15, itli...@schrievkrom.de wrote:
 
 Hello,
 
 I'm playing with WebSockets under Pharo4 and this works as expected -
 when using Pharo4 alone (using the Zinc packages).
 
 But I did not get it to work, when e.g. doing a proxying via nginx (I
 did not check it with Apache).
 
 Actually Pharo4 seems to receive some stuff, because the WebSocket of
 Pharo4 stuff does not work as expected after first proxying attempts.
 
 Has anyone experience with that ?
 
 Marten
>>> 
>>> Proxying the WebSockets protocol is not easy, nor implemented everywhere, 
>>> like HTTP is. This makes sense if you think about it, a WebSocket 
>>> connection is a permanent connection, which takes resources, this is not 
>>> something most servers like.
>>> 
>>> So it is more difficult.
>>> 
>>> Did you see/try http://nginx.org/en/docs/http/websocket.html ?
>>> 
>>> (I did not try it)
>>> 
>>> Sven
>>> 
>>> 
>> 
>> 
> 
> 
> -- 
> Marten Feldtmann
> 

Re: [Pharo-users] WebSocket and Proxying ...

[itli...@schrievkrom.de]

Good guess - but this does not help 

Marten

Am 06.05.2015 um 21:24 schrieb Sven Van Caekenberghe:
> Good that it works now, maybe your problem is that /ws-echo comes before and 
> maybe also matches /ws-echo-client ? But I am no nginx expert.
> 
> Maybe you try serving and proxying it as /client-ws-echo ? Or switch the 
> order ?
> 



-- 
Marten Feldtmann

Re: [Pharo-users] Halo Menu On Spec Tree Node

[Nicolai Hess]

2015-05-06 21:23 GMT+02:00 Sergio Fedi :

> Thanks for making the new case, I may resolve it soon.​
>

Good luck :)

I put a slice into the inbox, but that fix does not work , fo example:

RemotesManager new openWithSpec.

does not work anymore

[Pharo-users] SDL plugin ?

[Matthieu Lacaton]

Hello, I am currently playing with OSWindow and I am wondering what the
"SDL plugin" is in the OSSDL2Driver ?
When I downloaded the latest linux VM + image I got a library called
libSDL2DisplayPlugin but how can I get this plugin for windows ? Is it
possible to get the source code too ?

Thanks,

Matthieu

Re: [Pharo-users] SDL plugin ?

[Merwan Ouddane]

Hello Matthieu

The sdl plugin is just the SDL runtime binaries recompiled with the vm 
for eaach plateform, you can find the sources here: 
https://www.libsdl.org/release/SDL2-2.0.1.zip


The compiled plugin for windows can be found inside the last vm here: 
http://files.pharo.org/get-files/40/pharo-win-latest.zip


Cheers,
Merwan


On 06/05/2015 21:48, Matthieu Lacaton wrote:
Hello, I am currently playing with OSWindow and I am wondering what 
the "SDL plugin" is in the OSSDL2Driver ?
When I downloaded the latest linux VM + image I got a library called 
libSDL2DisplayPlugin but how can I get this plugin for windows ? Is it 
possible to get the source code too ?


Thanks,

Matthieu

Re: [Pharo-users] SDL plugin ?

[Esteban Lorenzano]

actually, the SDL plugin is not being included because until now it was not 
necessary. 
There is a difference between the SDL2 dependent functions and the plugin. 
The plugin provides just two functions: 

/**
 * Called by the VM heartbeat if installed, to check for the presence of events.
 */
static void ioCheckForEvents() {
if (inited) {
SDL_PumpEvents();
if (SDL_HasEvents(SDL_FIRSTEVENT, SDL_LASTEVENT)) {

interpreterProxy->signalSemaphoreWithIndex(inputSemaphoreIndex);
}
}
}

void setSDL2InputSemaphoreIndex(int semaIndex) {
inited = 1;
inputSemaphoreIndex = semaIndex;
setIoProcessEventsHandler(&ioCheckForEvents);
}

and they are used to replace the event handling the world uses… something that 
you cannot do at this moment because I did not integrate that chunk yet :)

So you should not need it… for now.

Esteban

ps: btw… this kind of questions are not for regular users but for pharo 
developers (because you are playing with something that is or will be part of 
pharo it self), so I’m redirecting this question there. 

> On 06 May 2015, at 22:03, Merwan Ouddane  wrote:
> 
> Hello Matthieu
> 
> The sdl plugin is just the SDL runtime binaries recompiled with the vm for 
> eaach plateform, you can find the sources here: 
> https://www.libsdl.org/release/SDL2-2.0.1.zip
> 
> The compiled plugin for windows can be found inside the last vm here: 
> http://files.pharo.org/get-files/40/pharo-win-latest.zip
> 
> Cheers,
> Merwan
> 
> 
> On 06/05/2015 21:48, Matthieu Lacaton wrote:
>> Hello, I am currently playing with OSWindow and I am wondering what the "SDL 
>> plugin" is in the OSSDL2Driver ?
>> When I downloaded the latest linux VM + image I got a library called 
>> libSDL2DisplayPlugin but how can I get this plugin for windows ? Is it 
>> possible to get the source code too ?
>> 
>> Thanks,
>> 
>> Matthieu
> 
> 

Re: [Pharo-users] Some Athens modifications ?

[Nicolai Hess]

2015-05-06 17:27 GMT+02:00 Matthieu Lacaton :

> Hello everybody,
>
> I was playing arround with Athens lately and I think I encountered a few
> small bugs along the way (I may be wrong though) :
>
> 1) In *LinearGradientPaint class >> from:* aStartPoint *to:* aStopPoint
> There is a call to the method *"initializeFrom: aStartPoint to:
> aStopPoint"* but this method does not exist. I think the whole method
> could probably be replaced by :
>

> *LinearGradientPaint class >>* *from:* aStartPoint *to:* aStopPoint
>   ^ self new start: aStartPoint; stop: aStopPoint; yourself.
>

Yes


>
> 2) This is not much but in the *GradientPaint* class there is an instance
> variable named *"stops"* but it seems that it is never used.
>

Yes, stops are part of the color ramp associations.


>
> 3) In AthensCairoMatrix there is a difference in the variable order
> between *AthensCairoMatrix class >> fieldsDesc* and *AthensCairoMatrix >>
> initx: y: sx: sy: shx: shy:*
>
> In the first one the order is "sx, shx, shy, sy, x, y" whereas in the
> second one it is "sx, shy, shx, sy, x, y". However, according to the
> cairoGraphics API documentation, the order should be the same.
>

I don't know why i t was done that way.


>
> By the way I have a small question : Why not keep the same variable names
> than in cairoGraphics here (xx, yx, xy, yy, x0, y0) ?
>

No idea :)


>
> 4) In *AthensCairoMatrix >> primMultiplyBy:* m.
>
> The function as defined in C is the following :
>
> void
> cairo_matrix_multiply (*cairo_matrix_t 
>  
> *result*,
>*const cairo_matrix_t 
>  
> *a*,
>*const cairo_matrix_t 
>  
> *b*);
>
> It is stated that
>
> *"The effect of the resulting transformation is to first apply the
> transformation in a to the coordinates and then apply the transformation in
> b to the coordinates."*
> In Pharo it is defined like this :
>
>
>
>
>
> *void   cairo_matrix_multiply (  AthensCairoMatrix * self,
>AthensCairoMatrix * m ,
>   AthensCairoMatrix * self )*
> For me, when writing "self multiplyBy: aRotationTransformation" it seems
> more logical to first do the self transformation" and then the rotation
> transformation (especially if we want a cascade of transformations).
> However, as currently written in Pharo it is actually the rotation
> transformation that is applied and then the self transformation.
>
> For example, if I want a scaling then a rotation then a translation it
> seems easier to me to do :
> myTransformation := myTransformation multiplyBy: scalingTransformation.
> myTransformation := myTransformation multiplyBy: rotationTransformation.
> myTransformation := myTransformation multiplyBy: translationTransformation.
> etc. if I want some other transformations.
>
> So it could be nice to have a
>
>
>
> *a method defined like this : void   cairo_matrix_multiply (
> AthensCairoMatrix * self,
> AthensCairoMatrix * self ,
> AthensCairoMatrix * m )*
>
>
> What do you think about it ?
>

maybe with different names post_multiply / pre_multiply ?



>
> Thanks,
>
> Matthieu
>
>

Re: [Pharo-users] SDL plugin ?

[Matthieu Lacaton]

Thanks for your answers, I understand now.
But even if the plugin is not needed it is handy to have because it allows
you to use "OSSDL2Driver current" without being returned an
OSNullWindowDriver because of the "hasPlugin" returning false.
Moreover the "eventLoopProcessWithPlugin" is actually much more efficient
than the "eventLoopWithoutPlugin" because of the semaphore.

So basically, even if it is not necessary, having the plugin just allows me
to code without hacking these methods :p

Thank you,

Matthieu

2015-05-06 22:32 GMT+02:00 Esteban Lorenzano :

> actually, the SDL plugin is not being included because until now it was
> not necessary.
> There is a difference between the SDL2 dependent functions and the plugin.
> The plugin provides just two functions:
>
> /**
>  * Called by the VM heartbeat if installed, to check for the presence of
> events.
>  */
> static void ioCheckForEvents() {
> if (inited) {
> SDL_PumpEvents();
> if (SDL_HasEvents(SDL_FIRSTEVENT, SDL_LASTEVENT)) {
> interpreterProxy->signalSemaphoreWithIndex(inputSemaphoreIndex);
> }
> }
> }
>
> void setSDL2InputSemaphoreIndex(int semaIndex) {
> inited = 1;
> inputSemaphoreIndex = semaIndex;
> setIoProcessEventsHandler(&ioCheckForEvents);
> }
>
> and they are used to replace the event handling the world uses… something
> that you cannot do at this moment because I did not integrate that chunk
> yet :)
>
> So you should not need it… for now.
>
> Esteban
>
> ps: btw… this kind of questions are not for regular users but for pharo
> developers (because you are playing with something that is or will be part
> of pharo it self), so I’m redirecting this question there.
>
> On 06 May 2015, at 22:03, Merwan Ouddane  wrote:
>
> Hello Matthieu
>
> The sdl plugin is just the SDL runtime binaries recompiled with the vm for
> eaach plateform, you can find the sources here:
> https://www.libsdl.org/release/SDL2-2.0.1.zip
>
> The compiled plugin for windows can be found inside the last vm here:
> http://files.pharo.org/get-files/40/pharo-win-latest.zip
>
> Cheers,
> Merwan
>
>
> On 06/05/2015 21:48, Matthieu Lacaton wrote:
>
> Hello, I am currently playing with OSWindow and I am wondering what the
> "SDL plugin" is in the OSSDL2Driver ?
> When I downloaded the latest linux VM + image I got a library called
> libSDL2DisplayPlugin but how can I get this plugin for windows ? Is it
> possible to get the source code too ?
>
> Thanks,
>
> Matthieu
>
>
>
>
>

Re: [Pharo-users] mac address on windows

[Henrik Sperre Johansen]

A few easily fixed Type/pointers to Types mixups, and a slipup where two
different classes are confused for the same aside, the real show stopper,
if I haven't missed something entirely, is that the struct parser/NB in
general does not handle const sized arrays*, which is used in a few of the
required structs.

Extending the parser should be relatively straight forward, along the lines
of adding
stream peek: #'[' ifTrue: [stream next.
   type := SizedExternalArrayType type: type size: stream next.
   stream next = #']' ifFalse: [self error: 'Missing closing bracket for ',
type printString]]
to NBExtenralStructureFields >> #parseFields:... after the name is read.

Coding SizedExternalArrayType is a bit more work though...

Cheers,
Henry


*The end goal would be to be able to generate accessors/read/write for a
simple test-struct such as
#fieldsDesc
^#(
  char   ip[MyClassVar +2];
)

On Wed, May 6, 2015 at 5:28 PM, Esteban Lorenzano 
wrote:

>
> On 06 May 2015, at 17:03, Nicolai Hess  wrote:
>
>
>
> 2015-05-06 16:40 GMT+02:00 Esteban Lorenzano :
>
>>
>> On 06 May 2015, at 12:10, p...@highoctane.be wrote:
>>
>> I've loaded your package.
>>
>> A prerequisite is to load OS-Window to make it work.
>>
>>
>> why?
>> in any case, oswindow is already included in pharo4
>>
>
> OS-Windows (by TorstenBergmann)
>
> not
> OSWindow  :)
>
>
> ahhh. Name clash :)
>
>
> It is needed for the shared pool WinTypes,
> but without OS-Window, he can use NBWinTypes instead.
>
>
>
>>
>> Esteban
>>
>>
>> I've got the DLL call working nicely and the nativeboost with the
>> structure freezing.
>>
>> Now, we should all have a look at:
>>
>> https://github.com/ronsaldo/bullet-pharo
>>
>> and
>>
>> https://github.com/ronsaldo/swig
>>
>> because it looks like the way to go to wrap libraries...
>>
>> Ronie, I know you modified swig for generating Pharo code;
>>
>> Is cloning your swig repo the way to go ?
>>
>>
>> Phil
>>
>>
>>
>>
>> On Wed, May 6, 2015 at 10:39 AM, Usman Bhatti 
>> wrote:
>>
>>> Hi Nicolai,
>>>
>>> Here is my package that defines the nativeboost call and associated C
>>> structs.
>>> The external C struct is self referencing and hence sometimes I get
>>> infinite recursion when trying to change field descriptions. That is the
>>> reason why the automatically generated accessors are absent (although I had
>>> them in an earlier version).
>>>
>>> Attached also the DLL referenced in the code.
>>>
>>>
>>>
>>> On Wed, May 6, 2015 at 9:58 AM, Nicolai Hess  wrote:
>>>


 2015-05-06 9:53 GMT+02:00 Usman Bhatti :

>
>
> On Tue, May 5, 2015 at 7:34 PM, p...@highoctane.be  > wrote:
>
>>
>> On Tue, May 5, 2015 at 6:28 PM, Usman Bhatti 
>> wrote:
>>
>>> I succeeded to do it by encapsulating the C routine as a DLL and
>>> doing an FFI call from my image (as suggested by Guille).
>>>
>>
>> At least there was a way!
>>
>
> Exactly :)
>
>
>>
>> Looks like this is the most controlled|debuggable way:
>>   - get it working with C code out of Pharo
>>   - make a bridge that can be used easily with FFI in a dll
>>   - use that from Pharo with proven FFI
>>
>> Would NativeBoost work with your dll? Should.
>>
>
> I have read a few resources about Nativeboost but I am still naive to
> know the difference between FFI and nativeboost. The FFI call I made to
> invoke the DLL function looked similar to the nativeboost calls.
>
>
>>
>>
>> I also tried to perform the nativeboost call by creating my
>>> structures in Pharo. The function in Windows that can be used to 
>>> retrieve
>>> mac address in Windows: GetAdaptersInfo
>>> 
>>>  that
>>> accepts a PIP_ADAPTER_INFO
>>> 
>>>  structure.
>>> I subclassed NBExternalStructure to define this struct and the other 
>>> used
>>> by it in the image but my NB call returned with 87 code (Invalid 
>>> parameter)
>>> and it was impossible to debug. However, I would like to make this thing
>>> work to understand what went wrong.
>>>
>>
>> Has this something to do with 32|64 bit library complications?
>>
>
> Not exactly. For me, it was more related to the fact that I had to map
> a complex C struct in Pharo. Here is an excerpt of the definition from 
> MSDN:
>
> typedef struct _IP_ADAPTER_INFO {
>   struct _IP_ADAPTER_INFO  *Next;
>  ...
>   PIP_ADDR_STRING CurrentIpAddress;
>   IP_ADDR_STRING  GatewayList;
> ...
> }
>
> So, I had to define three external structures (all names in capitals)
> and I did the effort but in the end I got an error code that I could not
> debug in the image. Hence, I gave up and opted to go in the native
>>>

Re: [Pharo-users] SDL plugin ?

[Esteban Lorenzano]

I can add them to the vm compilation. 
Adding it to the TODO… 

Esteban

ps: again, pharo-dev :)

> On 06 May 2015, at 22:45, Matthieu Lacaton  wrote:
> 
> Thanks for your answers, I understand now.
> But even if the plugin is not needed it is handy to have because it allows 
> you to use "OSSDL2Driver current" without being returned an 
> OSNullWindowDriver because of the "hasPlugin" returning false.
> Moreover the "eventLoopProcessWithPlugin" is actually much more efficient 
> than the "eventLoopWithoutPlugin" because of the semaphore.
> 
> So basically, even if it is not necessary, having the plugin just allows me 
> to code without hacking these methods :p
> 
> Thank you,
> 
> Matthieu
> 
> 2015-05-06 22:32 GMT+02:00 Esteban Lorenzano  >:
> actually, the SDL plugin is not being included because until now it was not 
> necessary. 
> There is a difference between the SDL2 dependent functions and the plugin. 
> The plugin provides just two functions: 
> 
> /**
>  * Called by the VM heartbeat if installed, to check for the presence of 
> events.
>  */
> static void ioCheckForEvents() {
> if (inited) {
> SDL_PumpEvents();
>   if (SDL_HasEvents(SDL_FIRSTEVENT, SDL_LASTEVENT)) {
>   
> interpreterProxy->signalSemaphoreWithIndex(inputSemaphoreIndex);
>   }
> }
> }
> 
> void setSDL2InputSemaphoreIndex(int semaIndex) {
> inited = 1;
> inputSemaphoreIndex = semaIndex;
> setIoProcessEventsHandler(&ioCheckForEvents);
> }
> 
> and they are used to replace the event handling the world uses… something 
> that you cannot do at this moment because I did not integrate that chunk yet 
> :)
> 
> So you should not need it… for now.
> 
> Esteban
> 
> ps: btw… this kind of questions are not for regular users but for pharo 
> developers (because you are playing with something that is or will be part of 
> pharo it self), so I’m redirecting this question there. 
> 
>> On 06 May 2015, at 22:03, Merwan Ouddane > > wrote:
>> 
>> Hello Matthieu
>> 
>> The sdl plugin is just the SDL runtime binaries recompiled with the vm for 
>> eaach plateform, you can find the sources here: 
>> https://www.libsdl.org/release/SDL2-2.0.1.zip 
>> 
>> 
>> The compiled plugin for windows can be found inside the last vm here: 
>> http://files.pharo.org/get-files/40/pharo-win-latest.zip 
>> 
>> 
>> Cheers,
>> Merwan
>> 
>> 
>> On 06/05/2015 21:48, Matthieu Lacaton wrote:
>>> Hello, I am currently playing with OSWindow and I am wondering what the 
>>> "SDL plugin" is in the OSSDL2Driver ?
>>> When I downloaded the latest linux VM + image I got a library called 
>>> libSDL2DisplayPlugin but how can I get this plugin for windows ? Is it 
>>> possible to get the source code too ?
>>> 
>>> Thanks,
>>> 
>>> Matthieu
>> 
>> 
> 
> 

Re: [Pharo-users] MouseWheel events

[Sean P. DeNigris]

Matthieu Lacaton wrote
> Shouldn't I get a MouseWheel event when i use the wheel and a keystroke
> when I use CTRL + Arrow ?

Yes! But the hack that you discovered is what we have :) It's done well for
us given it's simplicity. But it's far from ideal. For instance, IIRC the
delta is fixed, so scrolling a lot sends a lot of tiny scrolls instead of
more appropriately-sized ones. The keystroke-equivalence differences I think
are due to the underlying platform - the meta key for Mac is CMD, so that is
what's used. I extended the hack recently to get horizontal scrolling, but
it's only implemented for the Mac VM (there is not even corresponding code
in the image yet, pending Windows/Linux implementation). If you trap the
events, you can see that now it's simulating
cmd+alt+ctrl+shift+[up/down/left/right].



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/MouseWheel-events-tp4824839p4824929.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] mac address on windows

[Nicolai Hess]

2015-05-06 13:38 GMT+02:00 p...@highoctane.be :

>
>
> On Wed, May 6, 2015 at 12:29 PM, Nicolai Hess  wrote:
>
>>
>>
>> 2015-05-06 12:10 GMT+02:00 p...@highoctane.be :
>>
>>> I've loaded your package.
>>>
>>> A prerequisite is to load OS-Window to make it work.
>>>
>>> I've got the DLL call working nicely and the nativeboost with the
>>> structure freezing.
>>>
>>
>> This is because you have a recursive datastructure description, but
>> acutually the IP_ADAPTER_INFO structure is not recursive:
>>
>> PIP_ADAPTER_INFO class >>fieldsDex
>> ^ #(
>>  PIP_ADAPTER_INFO  nextVariable;
>>   DWORD   ComboIndex;
>>   CHARAdapterName;
>>   CHARDescription;
>> )
>>
>> The "nextVariable" should be a pointer to the structure.
>>
>> from MSDN:
>>
>>  struct _IP_ADAPTER_INFO {
>>   struct _IP_ADAPTER_INFO  *Next;   "<- pointer"
>>   DWORD   ComboIndex;
>>   charAdapterName[MAX_ADAPTER_NAME_LENGTH + 4];
>>   charDescription[MAX_ADAPTER_DESCRIPTION_LENGTH + 4];
>>   UINTAddressLength;
>>
>> 
>>
>>
>>
>
> So, what's to put in there then?
>
>
IpAdapterInfo class>>#fieldsDesc
^#(
  IpAdapterInfo*  Next;
  DWORD   ComboIndex;


This would work



> I can use FFI / NB for basic cases but never ventured into those structure.
> I'd like to :-)
>
> Phil
> I
>
>>
>>
>>
>>
>>
>>
>>
>>>
>>> Now, we should all have a look at:
>>>
>>> https://github.com/ronsaldo/bullet-pharo
>>>
>>> and
>>>
>>> https://github.com/ronsaldo/swig
>>>
>>> because it looks like the way to go to wrap libraries...
>>>
>>> Ronie, I know you modified swig for generating Pharo code;
>>>
>>> Is cloning your swig repo the way to go ?
>>>
>>>
>>> Phil
>>>
>>>
>>>
>>>
>>>
>>> On Wed, May 6, 2015 at 10:39 AM, Usman Bhatti 
>>> wrote:
>>>
 Hi Nicolai,

 Here is my package that defines the nativeboost call and associated C
 structs.
 The external C struct is self referencing and hence sometimes I get
 infinite recursion when trying to change field descriptions. That is the
 reason why the automatically generated accessors are absent (although I had
 them in an earlier version).

 Attached also the DLL referenced in the code.



 On Wed, May 6, 2015 at 9:58 AM, Nicolai Hess 
 wrote:

>
>
> 2015-05-06 9:53 GMT+02:00 Usman Bhatti :
>
>>
>>
>> On Tue, May 5, 2015 at 7:34 PM, p...@highoctane.be <
>> p...@highoctane.be> wrote:
>>
>>>
>>> On Tue, May 5, 2015 at 6:28 PM, Usman Bhatti >> > wrote:
>>>
 I succeeded to do it by encapsulating the C routine as a DLL and
 doing an FFI call from my image (as suggested by Guille).

>>>
>>> At least there was a way!
>>>
>>
>> Exactly :)
>>
>>
>>>
>>> Looks like this is the most controlled|debuggable way:
>>>   - get it working with C code out of Pharo
>>>   - make a bridge that can be used easily with FFI in a dll
>>>   - use that from Pharo with proven FFI
>>>
>>> Would NativeBoost work with your dll? Should.
>>>
>>
>> I have read a few resources about Nativeboost but I am still naive to
>> know the difference between FFI and nativeboost. The FFI call I made to
>> invoke the DLL function looked similar to the nativeboost calls.
>>
>>
>>>
>>>
>>> I also tried to perform the nativeboost call by creating my
 structures in Pharo. The function in Windows that can be used to 
 retrieve
 mac address in Windows: GetAdaptersInfo
 
  that
 accepts a PIP_ADAPTER_INFO
 
  structure.
 I subclassed NBExternalStructure to define this struct and the other 
 used
 by it in the image but my NB call returned with 87 code (Invalid 
 parameter)
 and it was impossible to debug. However, I would like to make this 
 thing
 work to understand what went wrong.

>>>
>>> Has this something to do with 32|64 bit library complications?
>>>
>>
>> Not exactly. For me, it was more related to the fact that I had to
>> map a complex C struct in Pharo. Here is an excerpt of the definition 
>> from
>> MSDN:
>>
>> typedef struct _IP_ADAPTER_INFO {
>>   struct _IP_ADAPTER_INFO  *Next;
>>  ...
>>   PIP_ADDR_STRING CurrentIpAddress;
>>   IP_ADDR_STRING  GatewayList;
>> ...
>> }
>>
>> So, I had to define three external structures (all names in capitals)
>> and I did the effort but in the end I got an error code that I could not
>> debug in the image. Hence, I gave up and opted to go in the native
>> environment. 

Re: [Pharo-users] mac address on windows

[Nicolai Hess]

2015-05-06 22:47 GMT+02:00 Henrik Sperre Johansen <
henrik.s.johan...@veloxit.no>:

> A few easily fixed Type/pointers to Types mixups, and a slipup where two
> different classes are confused for the same aside, the real show stopper,
> if I haven't missed something entirely, is that the struct parser/NB in
> general does not handle const sized arrays*, which is used in a few of the
> required structs.
>
> Extending the parser should be relatively straight forward, along the
> lines of adding
> stream peek: #'[' ifTrue: [stream next.
>type := SizedExternalArrayType type: type size: stream next.
>stream next = #']' ifFalse: [self error: 'Missing closing bracket for
> ', type printString]]
> to NBExtenralStructureFields >> #parseFields:... after the name is read.
>
> Coding SizedExternalArrayType is a bit more work though...
>
> Cheers,
> Henry
>
>
> *The end goal would be to be able to generate accessors/read/write for a
> simple test-struct such as
> #fieldsDesc
> ^#(
>   char   ip[MyClassVar +2];
> )
>

Yes, a parser for this would be great.

I tried it with a little hack

NBExternalStructure subclass: #Char_260 ...

Char_260 class>>#fieldDesc
^ #(char data)

Char_260 class>>instanceSize
^ 260

You need another accessor for accessing the data, otherwise you'll only get
the first char. AND I don't know how
the external memory is handle, probably it is never freed :)

Now a complete example (attached code) call it with
GetMacWin32 getMacAddress


>
> On Wed, May 6, 2015 at 5:28 PM, Esteban Lorenzano 
> wrote:
>
>>
>> On 06 May 2015, at 17:03, Nicolai Hess  wrote:
>>
>>
>>
>> 2015-05-06 16:40 GMT+02:00 Esteban Lorenzano :
>>
>>>
>>> On 06 May 2015, at 12:10, p...@highoctane.be wrote:
>>>
>>> I've loaded your package.
>>>
>>> A prerequisite is to load OS-Window to make it work.
>>>
>>>
>>> why?
>>> in any case, oswindow is already included in pharo4
>>>
>>
>> OS-Windows (by TorstenBergmann)
>>
>> not
>> OSWindow  :)
>>
>>
>> ahhh. Name clash :)
>>
>>
>> It is needed for the shared pool WinTypes,
>> but without OS-Window, he can use NBWinTypes instead.
>>
>>
>>
>>>
>>> Esteban
>>>
>>>
>>> I've got the DLL call working nicely and the nativeboost with the
>>> structure freezing.
>>>
>>> Now, we should all have a look at:
>>>
>>> https://github.com/ronsaldo/bullet-pharo
>>>
>>> and
>>>
>>> https://github.com/ronsaldo/swig
>>>
>>> because it looks like the way to go to wrap libraries...
>>>
>>> Ronie, I know you modified swig for generating Pharo code;
>>>
>>> Is cloning your swig repo the way to go ?
>>>
>>>
>>> Phil
>>>
>>>
>>>
>>>
>>> On Wed, May 6, 2015 at 10:39 AM, Usman Bhatti 
>>> wrote:
>>>
 Hi Nicolai,

 Here is my package that defines the nativeboost call and associated C
 structs.
 The external C struct is self referencing and hence sometimes I get
 infinite recursion when trying to change field descriptions. That is the
 reason why the automatically generated accessors are absent (although I had
 them in an earlier version).

 Attached also the DLL referenced in the code.



 On Wed, May 6, 2015 at 9:58 AM, Nicolai Hess 
 wrote:

>
>
> 2015-05-06 9:53 GMT+02:00 Usman Bhatti :
>
>>
>>
>> On Tue, May 5, 2015 at 7:34 PM, p...@highoctane.be <
>> p...@highoctane.be> wrote:
>>
>>>
>>> On Tue, May 5, 2015 at 6:28 PM, Usman Bhatti >> > wrote:
>>>
 I succeeded to do it by encapsulating the C routine as a DLL and
 doing an FFI call from my image (as suggested by Guille).

>>>
>>> At least there was a way!
>>>
>>
>> Exactly :)
>>
>>
>>>
>>> Looks like this is the most controlled|debuggable way:
>>>   - get it working with C code out of Pharo
>>>   - make a bridge that can be used easily with FFI in a dll
>>>   - use that from Pharo with proven FFI
>>>
>>> Would NativeBoost work with your dll? Should.
>>>
>>
>> I have read a few resources about Nativeboost but I am still naive to
>> know the difference between FFI and nativeboost. The FFI call I made to
>> invoke the DLL function looked similar to the nativeboost calls.
>>
>>
>>>
>>>
>>> I also tried to perform the nativeboost call by creating my
 structures in Pharo. The function in Windows that can be used to 
 retrieve
 mac address in Windows: GetAdaptersInfo
 
  that
 accepts a PIP_ADAPTER_INFO
 
  structure.
 I subclassed NBExternalStructure to define this struct and the other 
 used
 by it in the image but my NB call returned with 87 code (Invalid 
 parameter)
 and it was impossible to debug. However, I would like to make this 
 thing
>>>

Re: [Pharo-users] Problems in switching from Moose 5.0 (Pharo 3) to Moose 5.1 (Pharo 4)

[PBKResearch]

Vincent

 

Sorry for the delay in replying. The point about (TLTextTokenizer parse:
'test' startingAt: #word) is weird. You are quite right, it does give a
PPToken in Pharo #40613. In #40612 it gave an array of PPToken – I checked
this before sending the original message and again after receiving your
first reply, and I have now rescued my #40612 image from the recycle bin and
tested it again. We are using the same version, by the way – except that I
have now modified mine to remove the deprecated method ‘value’.

 

The behaviour of TLTextTokenizer in the latest image is very odd. It seems
to parse only the first word of any text even when I don’t specify
startingAt: #word. For instance, if I enter (TLTextTokenizer parse: 'test
run' ), the result is aPPToken on ‘test’. However, it is not clear that we
are meant to use TLTextTokenizer at all; the organisation of the TextLint
parsers suggests this is an abstract superclass, and the checkers seem to
use  TLPatternTokenizer or TLPlainTokenizer and its subclasses exclusively.
I have used TLPlainTokenizer with only one oddity, namely that it would not
display the result of (TLPlainTokenizer parse: ‘test run’) in the
PetitParser browser until I changed (TLTerminatorMark with: ‘’) to
(TLTerminatorMark with: (PPToken on: ‘’)) in the elementList method.

 

I have spent probably far too long today exploring TextLint, particularly
trying to find why so many of the tests fail. It looks as though,  since
many of them were written, PetitParser has been changed in many details.
Anyway, I can now use TLTextLintChecker to give me a parse of any plain text
as a structured document, which was my original objective, so I can get back
to my project - using Pharo 4.

 

Thanks for your help.

 

Peter Kenny

 

From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of
Blondeau Vincent
Sent: 06 May 2015 12:57
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Problems in switching from Moose 5.0 (Pharo 3) to
Moose 5.1 (Pharo 4)

 

 

 

De : Pharo-users [ 
mailto:pharo-users-boun...@lists.pharo.org] De la part de PBKResearch
Envoyé : mercredi 6 mai 2015 12:12
À : 'Any question about pharo is welcome'
Objet : Re: [Pharo-users] Problems in switching from Moose 5.0 (Pharo 3) to
Moose 5.1 (Pharo 4)

 

Vincent

Peter,

Many thanks. You have solved the problem and educated me in the process –
since I now know how to do a user interrupt – I was pressing Ctrl-Break with
no effect. The problem was the looping of the deprecation notifier, which I
can fix by removing the deprecated ‘value’ message. The looping should not
have occurred, and there must be a bug somewhere, but it’s not my problem.

Actually, the notify message open a debugger and “value” message is send by
the debugger, but value send a notify message that opens a new debugger…
etc… I don’t think that is a bug. It is not the notify: method that should
be used but the deprecated: one.

 

One little detail, about your comment on point 6 below. On my system,
(TLTextTokenizer parse: 'test' startingAt: #word) generates an array of
PPToken, so it does not understand parsedValue. Are we looking at different
versions of TextLint?

TLTextTokenizer parse: 'test' startingAt: #word return a PPToken, not an
array on PPToken in the version I have.

I have this version of TextLint : 

Name: TextLint-Model-JorgeRessia.225

Author: JorgeRessia

Time: 10 February 2012, 2:41:11 pm

UUID: 3c6965a4-bc1f-42e4-b309-fab8e4303046

Ancestors: TextLint-Model-lr.224

 

Name: TextLint-Tests-lr.166

Author: lr

Time: 25 March 2012, 10:46:49 am

UUID: ed387b31-02e6-4194-91e6-18d3879dc858

Ancestors: TextLint-Tests-DamienCassou.165

 

And petit parser:

Name: PetitParser-JanKurs.278

Author: JanKurs

Time: 5 May 2015, 2:39:26.475846 pm

UUID: 55ae813a-5dfd-4b4d-a98b-274f5431331e

Ancestors: PetitParser-JanKurs.277, PetitParser-JanKurs.276

 

Vincent Blondeau

 

Thanks again

 

Peter Kenny

 

From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of
Blondeau Vincent
Sent: 06 May 2015 10:00
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Problems in switching from Moose 5.0 (Pharo 3) to
Moose 5.1 (Pharo 4)

 

 

De : Pharo-users [ 
mailto:pharo-users-boun...@lists.pharo.org] De la part de PBKResearch
Envoyé : mardi 5 mai 2015 18:01
À :   pharo-users@lists.pharo.org
Objet : [Pharo-users] Problems in switching from Moose 5.0 (Pharo 3) to
Moose 5.1 (Pharo 4)

Hello,

 

I have been working with Moose 5.0 on a project involving natural language
processing. I used TextLint to parse the input, just because it contained a
set of parsers which gave output in a convenient form. I have read all about
the virtues of Pharo 4, and decided to give it a try, so I set out to
reproduce the earlier results. I have run into a number of problems –
basically I haven’t been abl