November 2016 - Pharo-users

Re: [Pharo-users] Converting an Array of Characters to a String

by Igor Stasenko

What i meant, i wanted to warn Dimitris that char[100] are just array of 100 characters (bytes in C).. and has nothing to do with strings. Do not confuse fixed-length C arrays with strings. There's no 'string' data type in C, and instead they use null-terminated character sequence as a convention. But it is not a fixed-size data. On 9 November 2016 at 02:38, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 8 November 2016 at 14:42, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> (always with Char100 example in mind): >> >> s := MyStructure fromHandle: blah. >> string := s data readString. >> >> should work. >> >> > IIRC, #readString works correctly only for correctly null-terminated > strings. If not, it will read beyond the structure size , until it find a > zero byte somewhere in memory, > and thus, results may vary :) > > >> Esteban >> >> >> > On 8 Nov 2016, at 14:31, Dimitris Chloupis <kilon.alios(a)gmail.com> >> wrote: >> > >> > I feel like stupid but I cannot find a way to convert an Array of >> Characters to a String , I can do with a do: and join characters converted >> to strings to a single string but it feels too many steps. >> > >> > Is there a simpler way ? >> >> >> > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

Nov. 9, 2016

Re: [Pharo-users] Converting an Array of Characters to a String

by Igor Stasenko

On 8 November 2016 at 14:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > (always with Char100 example in mind): > > s := MyStructure fromHandle: blah. > string := s data readString. > > should work. > > IIRC, #readString works correctly only for correctly null-terminated strings. If not, it will read beyond the structure size , until it find a zero byte somewhere in memory, and thus, results may vary :) > Esteban > > > > On 8 Nov 2016, at 14:31, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > I feel like stupid but I cannot find a way to convert an Array of > Characters to a String , I can do with a do: and join characters converted > to strings to a single string but it feels too many steps. > > > > Is there a simpler way ? > > > -- Best regards, Igor Stasenko.

Nov. 9, 2016

Re: [Pharo-users] UFFI can not generate Structure accessor of type char[100]

by Igor Stasenko

On 8 November 2016 at 13:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 8 Nov 2016, at 12:55, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Thank you Esteban > > By the way I really love the design of UFFI , very clean and quite easy to > understand , great work to you and Igor :) > > > UFFI is just mine ;) > (but I sanded in giant shoulders as I took Igor work as inspirationâ¦ and > to âborrowâ many cool ideas) > > Your credit is too generous :) Btw, is this expression: FFITypeArray ofType: #char. creates anonymous class, or you making an instance of something? Because if it anonymous class, i was always warned against use it in such form, and instead use some kind of class initializers to generate all the 'types' you will use in future i.e. MyCalss class>>initialize MyCharr100Type := FFITypeArray ofType: #char size:100. and then just use it wherever you need i.e.: mychars := MyChar100Type new. .. whatever. > Esteban > > > On Tue, Nov 8, 2016 at 1:54 PM Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> On 8 Nov 2016, at 12:49, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >> >> I was reaching a similar conclusion >> >> Currently I have a void pointer to the struct with the members I >> mentioned >> >> I can get char[100] >> >> pointerToStruct fromCString >> >> and I can get the int with >> >> pointerToStruct getHandle integerAt: 101 size:4 signed: false >> >> so if I want to pass the address of the pointer to my YourStruct instance >> will I have to initialize with >> >> YourStruct fromHandler: (pointerToStruct getHandle) >> >> is this a correct and safe way to pass the address ? >> >> >> yes. >> >> Esteban >> >> >> >> On Tue, Nov 8, 2016 at 1:21 PM Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >> it never could. >> you need to do a âspecial typeâ, who has to be something like: >> >> YourStruct class>>initialize >> Char100 := FFITypeArray ofType: #char. >> >> fieldsDesc >> ^ #( >> Char100 data; >> int count; >> ) >> >> but thenâ¦ you want to optimise that and in field accessors, who will look >> something like this: >> >> YourStruct >>data >> "This method was automatically generated" >> ^(FFITypeArray ofType: #char size: 100) fromHandle: (handle >> copyFrom: 1 to: 100) >> >> you can change that for: >> >> YourStruct >>data >> "This method was automatically generated" >> ^Char100 fromHandle: (handle copyFrom: 1 to: 100) >> >> and same for setter. >> (other way will work, but it will be suboptimal) >> >> Esteban >> >> > On 8 Nov 2016, at 12:10, Dimitris Chloupis <kilon.alios(a)gmail.com> >> wrote: >> > >> > I have FFIExternalStructure which has at class side >> > >> > fieldsDesc >> > ^#( >> > char data[100]; >> > int count; >> > ) >> > >> > if I try to do >> > >> > EphCPPTestStructure rebuildFieldAccessors . >> > >> > in order to generate the accessors for the members of the struct it >> complains with an error that it does not recognise the type of " [ " >> > >> > Does that mean that char arrays are other arrays are not supported as >> struct members or will I have to do this manually ? >> >> >> > -- Best regards, Igor Stasenko.

Nov. 9, 2016

Re: [Pharo-users] [ANN] CPPBridge: One Ring to rule them ALL

by Igor Stasenko

On 9 November 2016 at 02:09, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > I have only played with c structs and it looks like they do the job fine . > If json parsing is slow especially in Pharo then it's out of the question. > Parsing must be kept close to zero because I will be running some very > tight loops of 100 frames per second and there is no way that I will let > Pharo take its time as the whole idea of using the fastest way to IPC was > to keep Pharo in sync with unreal . Heavy lifting will be done only by > Unreal. Pharo will be used just for logic. > > Well, it depends what you want: if you want to give away a complete/general solution for IPC with Pharo via shared memory, then you should create some kind of library (both C++ and Pharo) which would allow users to setup the bridge configuration in the way they want, leaving the application-specific exchange to the hands of users.. And if you just want to make own data exchange for own purpose, then you are basically done. > In any case there is a ton of testing and profiling needed to be done . So > these are just the first steps. > On Wed, 9 Nov 2016 at 02:58, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> JSON? -- But you were talking about speed. Once you put JSON as a base >> for IPC, then say goodbye to speed. >> >> Because JSON parsing/writing will eat like 90% of time even if you would >> use sockets. >> So, why not using some kind of binary protocol? >> Unless you wanna use JSON for initial handshaking exchange. Then it is >> quite reasonable. >> >> But all of that still won't free you from inventing some kind of >> contract(s) which would allow parties to agree who writes where and/or who >> writes, while other waits then reads etc. >> >> >> On 9 November 2016 at 00:06, Dimitris Chloupis <kilon.alios(a)gmail.com> >> wrote: >> >> >> *https://youtu.be/pI4PR3XaX6Q <https://youtu.be/pI4PR3XaX6Q>* >> >> *What is it ?* >> >> CPPBridge is a library that allows Pharo to share memory with any C/C++ >> application. Opening the door not only to IPC and data sharing but also >> even complete control of C++ code from Pharo and vice versa. >> >> *How to install ?* >> >> In a few hours it should be available from Package Browser, if not you >> can always fetch it with Metacello from here because it comes with a >> Baseline >> >> https://github.com/kilon/CPPBridge >> >> *Why bother making such a library ? * >> >> In my saga to find a way to use Pharo as a scripting language for Unreal >> Game Engine, I had two options >> >> a) Build Unreal as a Library and use Pharo UFFI to launch and control it >> b) Embed Pharo inside the Unreal Executable (this is what every other >> scripting language uses for controlling Unreal) >> >> Option (a) was a no go, because Unreal is huge , complex and uses its own >> custom made build tools, making a DLL for Pharo or an army of DLLs out of >> the question >> >> Option (b) Embeding Pharo inside an executable is impossible and >> implementing it also insanely complex >> >> Naturally my mind went first into sockets which is what I use to make >> Pharo able to use Python libraries. However sockets have proven too slow >> for the insanely fast loops of Unreal. >> >> *What are the advantages ?* >> >> 1) *No need to move data around.* Sharing memory means you don't have to >> move data around, you can use directly the shared memory >> >> 2)* Extend the Pharo image beyond Pharo.* Shared memory is mapped into a >> file means that you can do with C++ what you can do with Pharo image, save >> the live state directly to a binary file. That means we no longer need to >> worry about sessions and reinitializing C/C++ data since memory mapped file >> acts as an extension of the Pharo image. >> >> 3) *Blazing fast. *Memory mapping is a function that comes directly from >> the OS kernel and as such it has to be extremely fast. Memory mapping is >> also what is used for dynamically linked shared libraries an extremely >> important feature for any application including Pharo that heavily depends >> on (see Cairo for Athens). So its a very mature , well tested method. >> >> 4) *No extra libraries needed* to be installed, CPPBridge uses OS >> libraries to work out of the box >> >> 5) *Low level handling of memory.* Direct access to memory you can even >> manipulate the memory byte by byte >> >> 6)* Memory efficient.* Memory mapping excels at large data, the bigger >> the better. Can take full advantage of your entire free memory and not >> waste a byte. That means also that can be used to optimise Pharo memory, >> since you could compress your Pharo objects to bytes and mapped file will >> store the live state. >> >> 7) *Tons of Languages. *Because memory mapping is a core functionality >> for every OS out there, pretty much every programming language supports it. >> CPPBridge currently supports only C/C++ but all languages can be supported >> giving access to Pharo to any library for any programming language. Sky is >> the limit >> >> 8) *Self Documented. *CPPBridge is small, simple and with large class >> comment and comments for every method. YouTube video tutorial also >> available and linked on top. >> >> 9) *Works both ways*, C/C++ and Pharo can access and modify the shared >> memory. Making it possible for C/C++ to use Pharo libraries and Pharo to >> use C/C++ libraries. >> >> 10) Experiments have proven that it improves sex life... if it does not >> please file a bug report ;) >> >> >> *What are the disadvantages ?* >> >> 1) *Candy Crash Saga*. Dare do something incorrectly and Pharo will >> crash. CPPBridge can easily point to wrong address if you are not aware of >> what you doing. >> >> 2) *C++/C* . If you think you can avoid learning C/C++ and that this is >> a magic solution , think again. The C/C++ application must be modified to >> include shared memory mapping for CPPBridge to work . >> >> 3) *Local only*. Unlike sockets, Shared Memory works only on the same >> machine so no remote execution and manipulation of code like in my socket >> bridge to Python >> >> 4) *UFFI still No1 option*. No replacement for UFFI it actually depends >> on it to work , so if you can turn your C/C++ code into a DLL that should >> be your first option. >> >> *Roadmap * >> >> Currently CPPBridge works only on MacOS , most likely on Linux too >> (because it uses the Unix architecture) but I will have to test it. >> >> Windows is coming next ASAP, since its my No1 platform for creating >> commercial games. >> >> Maybe establish a small protocol of communication via the Shared Memory , >> JSON looks like a good universal format >> >> *Thanks* >> >> Big thanks to Eliot for inspiring me and Esteban for helping me figure >> out things. >> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

Nov. 9, 2016

Re: [Pharo-users] [ANN] CPPBridge: One Ring to rule them ALL

by Dimitris Chloupis

I have only played with c structs and it looks like they do the job fine . If json parsing is slow especially in Pharo then it's out of the question. Parsing must be kept close to zero because I will be running some very tight loops of 100 frames per second and there is no way that I will let Pharo take its time as the whole idea of using the fastest way to IPC was to keep Pharo in sync with unreal . Heavy lifting will be done only by Unreal. Pharo will be used just for logic. In any case there is a ton of testing and profiling needed to be done . So these are just the first steps. On Wed, 9 Nov 2016 at 02:58, Igor Stasenko <siguctua(a)gmail.com> wrote: > JSON? -- But you were talking about speed. Once you put JSON as a base for > IPC, then say goodbye to speed. > > Because JSON parsing/writing will eat like 90% of time even if you would > use sockets. > So, why not using some kind of binary protocol? > Unless you wanna use JSON for initial handshaking exchange. Then it is > quite reasonable. > > But all of that still won't free you from inventing some kind of > contract(s) which would allow parties to agree who writes where and/or who > writes, while other waits then reads etc. > > > On 9 November 2016 at 00:06, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > *https://youtu.be/pI4PR3XaX6Q <https://youtu.be/pI4PR3XaX6Q>* > > *What is it ?* > > CPPBridge is a library that allows Pharo to share memory with any C/C++ > application. Opening the door not only to IPC and data sharing but also > even complete control of C++ code from Pharo and vice versa. > > *How to install ?* > > In a few hours it should be available from Package Browser, if not you can > always fetch it with Metacello from here because it comes with a Baseline > > https://github.com/kilon/CPPBridge > > *Why bother making such a library ? * > > In my saga to find a way to use Pharo as a scripting language for Unreal > Game Engine, I had two options > > a) Build Unreal as a Library and use Pharo UFFI to launch and control it > b) Embed Pharo inside the Unreal Executable (this is what every other > scripting language uses for controlling Unreal) > > Option (a) was a no go, because Unreal is huge , complex and uses its own > custom made build tools, making a DLL for Pharo or an army of DLLs out of > the question > > Option (b) Embeding Pharo inside an executable is impossible and > implementing it also insanely complex > > Naturally my mind went first into sockets which is what I use to make > Pharo able to use Python libraries. However sockets have proven too slow > for the insanely fast loops of Unreal. > > *What are the advantages ?* > > 1) *No need to move data around.* Sharing memory means you don't have to > move data around, you can use directly the shared memory > > 2)* Extend the Pharo image beyond Pharo.* Shared memory is mapped into a > file means that you can do with C++ what you can do with Pharo image, save > the live state directly to a binary file. That means we no longer need to > worry about sessions and reinitializing C/C++ data since memory mapped file > acts as an extension of the Pharo image. > > 3) *Blazing fast. *Memory mapping is a function that comes directly from > the OS kernel and as such it has to be extremely fast. Memory mapping is > also what is used for dynamically linked shared libraries an extremely > important feature for any application including Pharo that heavily depends > on (see Cairo for Athens). So its a very mature , well tested method. > > 4) *No extra libraries needed* to be installed, CPPBridge uses OS > libraries to work out of the box > > 5) *Low level handling of memory.* Direct access to memory you can even > manipulate the memory byte by byte > > 6)* Memory efficient.* Memory mapping excels at large data, the bigger > the better. Can take full advantage of your entire free memory and not > waste a byte. That means also that can be used to optimise Pharo memory, > since you could compress your Pharo objects to bytes and mapped file will > store the live state. > > 7) *Tons of Languages. *Because memory mapping is a core functionality > for every OS out there, pretty much every programming language supports it. > CPPBridge currently supports only C/C++ but all languages can be supported > giving access to Pharo to any library for any programming language. Sky is > the limit > > 8) *Self Documented. *CPPBridge is small, simple and with large class > comment and comments for every method. YouTube video tutorial also > available and linked on top. > > 9) *Works both ways*, C/C++ and Pharo can access and modify the shared > memory. Making it possible for C/C++ to use Pharo libraries and Pharo to > use C/C++ libraries. > > 10) Experiments have proven that it improves sex life... if it does not > please file a bug report ;) > > > *What are the disadvantages ?* > > 1) *Candy Crash Saga*. Dare do something incorrectly and Pharo will > crash. CPPBridge can easily point to wrong address if you are not aware of > what you doing. > > 2) *C++/C* . If you think you can avoid learning C/C++ and that this is a > magic solution , think again. The C/C++ application must be modified to > include shared memory mapping for CPPBridge to work . > > 3) *Local only*. Unlike sockets, Shared Memory works only on the same > machine so no remote execution and manipulation of code like in my socket > bridge to Python > > 4) *UFFI still No1 option*. No replacement for UFFI it actually depends > on it to work , so if you can turn your C/C++ code into a DLL that should > be your first option. > > *Roadmap * > > Currently CPPBridge works only on MacOS , most likely on Linux too > (because it uses the Unix architecture) but I will have to test it. > > Windows is coming next ASAP, since its my No1 platform for creating > commercial games. > > Maybe establish a small protocol of communication via the Shared Memory , > JSON looks like a good universal format > > *Thanks* > > Big thanks to Eliot for inspiring me and Esteban for helping me figure out > things. > > > > > -- > Best regards, > Igor Stasenko. >

Nov. 9, 2016

Re: [Pharo-users] [ANN] CPPBridge: One Ring to rule them ALL

by Igor Stasenko

JSON? -- But you were talking about speed. Once you put JSON as a base for IPC, then say goodbye to speed. Because JSON parsing/writing will eat like 90% of time even if you would use sockets. So, why not using some kind of binary protocol? Unless you wanna use JSON for initial handshaking exchange. Then it is quite reasonable. But all of that still won't free you from inventing some kind of contract(s) which would allow parties to agree who writes where and/or who writes, while other waits then reads etc. On 9 November 2016 at 00:06, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > *https://youtu.be/pI4PR3XaX6Q <https://youtu.be/pI4PR3XaX6Q>* > > *What is it ?* > > CPPBridge is a library that allows Pharo to share memory with any C/C++ > application. Opening the door not only to IPC and data sharing but also > even complete control of C++ code from Pharo and vice versa. > > *How to install ?* > > In a few hours it should be available from Package Browser, if not you can > always fetch it with Metacello from here because it comes with a Baseline > > https://github.com/kilon/CPPBridge > > *Why bother making such a library ? * > > In my saga to find a way to use Pharo as a scripting language for Unreal > Game Engine, I had two options > > a) Build Unreal as a Library and use Pharo UFFI to launch and control it > b) Embed Pharo inside the Unreal Executable (this is what every other > scripting language uses for controlling Unreal) > > Option (a) was a no go, because Unreal is huge , complex and uses its own > custom made build tools, making a DLL for Pharo or an army of DLLs out of > the question > > Option (b) Embeding Pharo inside an executable is impossible and > implementing it also insanely complex > > Naturally my mind went first into sockets which is what I use to make > Pharo able to use Python libraries. However sockets have proven too slow > for the insanely fast loops of Unreal. > > *What are the advantages ?* > > 1) *No need to move data around.* Sharing memory means you don't have to > move data around, you can use directly the shared memory > > 2)* Extend the Pharo image beyond Pharo.* Shared memory is mapped into a > file means that you can do with C++ what you can do with Pharo image, save > the live state directly to a binary file. That means we no longer need to > worry about sessions and reinitializing C/C++ data since memory mapped file > acts as an extension of the Pharo image. > > 3) *Blazing fast. *Memory mapping is a function that comes directly from > the OS kernel and as such it has to be extremely fast. Memory mapping is > also what is used for dynamically linked shared libraries an extremely > important feature for any application including Pharo that heavily depends > on (see Cairo for Athens). So its a very mature , well tested method. > > 4) *No extra libraries needed* to be installed, CPPBridge uses OS > libraries to work out of the box > > 5) *Low level handling of memory.* Direct access to memory you can even > manipulate the memory byte by byte > > 6)* Memory efficient.* Memory mapping excels at large data, the bigger > the better. Can take full advantage of your entire free memory and not > waste a byte. That means also that can be used to optimise Pharo memory, > since you could compress your Pharo objects to bytes and mapped file will > store the live state. > > 7) *Tons of Languages. *Because memory mapping is a core functionality > for every OS out there, pretty much every programming language supports it. > CPPBridge currently supports only C/C++ but all languages can be supported > giving access to Pharo to any library for any programming language. Sky is > the limit > > 8) *Self Documented. *CPPBridge is small, simple and with large class > comment and comments for every method. YouTube video tutorial also > available and linked on top. > > 9) *Works both ways*, C/C++ and Pharo can access and modify the shared > memory. Making it possible for C/C++ to use Pharo libraries and Pharo to > use C/C++ libraries. > > 10) Experiments have proven that it improves sex life... if it does not > please file a bug report ;) > > > *What are the disadvantages ?* > > 1) *Candy Crash Saga*. Dare do something incorrectly and Pharo will > crash. CPPBridge can easily point to wrong address if you are not aware of > what you doing. > > 2) *C++/C* . If you think you can avoid learning C/C++ and that this is a > magic solution , think again. The C/C++ application must be modified to > include shared memory mapping for CPPBridge to work . > > 3) *Local only*. Unlike sockets, Shared Memory works only on the same > machine so no remote execution and manipulation of code like in my socket > bridge to Python > > 4) *UFFI still No1 option*. No replacement for UFFI it actually depends > on it to work , so if you can turn your C/C++ code into a DLL that should > be your first option. > > *Roadmap * > > Currently CPPBridge works only on MacOS , most likely on Linux too > (because it uses the Unix architecture) but I will have to test it. > > Windows is coming next ASAP, since its my No1 platform for creating > commercial games. > > Maybe establish a small protocol of communication via the Shared Memory , > JSON looks like a good universal format > > *Thanks* > > Big thanks to Eliot for inspiring me and Esteban for helping me figure out > things. > -- Best regards, Igor Stasenko.

Nov. 9, 2016

Re: [Pharo-users] [ANN] Introspect web content (Soup with some GT extensions)

by Offray Vladimir Luna CÃ¡rdenas

Hi again, I was using Torsten extension today and thought that some contextual buttons could be interesting. For example, suppose I am browsing a particular soup (like in [1]) and I find that I would like to save a particular element or the whole tree. Would be nice to have a small menu button to choose between such options in the Soup tree. How can I add such button? [1] https://pbs.twimg.com/media/CwxveZAWEAEMlVh.jpg:large Thanks, Offray On 14/04/16 12:29, Offray Vladimir Luna CÃ¡rdenas wrote: > Thanks a lot! Pretty useful on web scrapping and workshops. > > Cheers, > > Offray > > On 14/04/16 11:04, Tudor Girba wrote: >> Nice! >> >> Doru >> >> >>> On Apr 14, 2016, at 4:01 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >>> >>> Hi, >>> >>> I added a few GT inspector extensions to Soup and cleaned up a >>> little bit. >>> Released as a new version 1.8 of Soup - you will find easily in Catalog >>> for Pharo 5 or by opening Spotter and entering "Soup" to load. >>> >>> As the attached screenshots shows you now have a nice way to introspect >>> the structure of a web page as a tree in the inspector or see the >>> attributes of tags/nodes in a table. >>> >>> Thx >>> T. >>> <soup.png> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Value is always contextual." >> >> >> >> >> >> > > >

Nov. 8, 2016

[ANN] CPPBridge: One Ring to rule them ALL

by Dimitris Chloupis

*https://youtu.be/pI4PR3XaX6Q <https://youtu.be/pI4PR3XaX6Q>* *What is it ?* CPPBridge is a library that allows Pharo to share memory with any C/C++ application. Opening the door not only to IPC and data sharing but also even complete control of C++ code from Pharo and vice versa. *How to install ?* In a few hours it should be available from Package Browser, if not you can always fetch it with Metacello from here because it comes with a Baseline https://github.com/kilon/CPPBridge *Why bother making such a library ? * In my saga to find a way to use Pharo as a scripting language for Unreal Game Engine, I had two options a) Build Unreal as a Library and use Pharo UFFI to launch and control it b) Embed Pharo inside the Unreal Executable (this is what every other scripting language uses for controlling Unreal) Option (a) was a no go, because Unreal is huge , complex and uses its own custom made build tools, making a DLL for Pharo or an army of DLLs out of the question Option (b) Embeding Pharo inside an executable is impossible and implementing it also insanely complex Naturally my mind went first into sockets which is what I use to make Pharo able to use Python libraries. However sockets have proven too slow for the insanely fast loops of Unreal. *What are the advantages ?* 1) *No need to move data around.* Sharing memory means you don't have to move data around, you can use directly the shared memory 2)* Extend the Pharo image beyond Pharo.* Shared memory is mapped into a file means that you can do with C++ what you can do with Pharo image, save the live state directly to a binary file. That means we no longer need to worry about sessions and reinitializing C/C++ data since memory mapped file acts as an extension of the Pharo image. 3) *Blazing fast. *Memory mapping is a function that comes directly from the OS kernel and as such it has to be extremely fast. Memory mapping is also what is used for dynamically linked shared libraries an extremely important feature for any application including Pharo that heavily depends on (see Cairo for Athens). So its a very mature , well tested method. 4) *No extra libraries needed* to be installed, CPPBridge uses OS libraries to work out of the box 5) *Low level handling of memory.* Direct access to memory you can even manipulate the memory byte by byte 6)* Memory efficient.* Memory mapping excels at large data, the bigger the better. Can take full advantage of your entire free memory and not waste a byte. That means also that can be used to optimise Pharo memory, since you could compress your Pharo objects to bytes and mapped file will store the live state. 7) *Tons of Languages. *Because memory mapping is a core functionality for every OS out there, pretty much every programming language supports it. CPPBridge currently supports only C/C++ but all languages can be supported giving access to Pharo to any library for any programming language. Sky is the limit 8) *Self Documented. *CPPBridge is small, simple and with large class comment and comments for every method. YouTube video tutorial also available and linked on top. 9) *Works both ways*, C/C++ and Pharo can access and modify the shared memory. Making it possible for C/C++ to use Pharo libraries and Pharo to use C/C++ libraries. 10) Experiments have proven that it improves sex life... if it does not please file a bug report ;) *What are the disadvantages ?* 1) *Candy Crash Saga*. Dare do something incorrectly and Pharo will crash. CPPBridge can easily point to wrong address if you are not aware of what you doing. 2) *C++/C* . If you think you can avoid learning C/C++ and that this is a magic solution , think again. The C/C++ application must be modified to include shared memory mapping for CPPBridge to work . 3) *Local only*. Unlike sockets, Shared Memory works only on the same machine so no remote execution and manipulation of code like in my socket bridge to Python 4) *UFFI still No1 option*. No replacement for UFFI it actually depends on it to work , so if you can turn your C/C++ code into a DLL that should be your first option. *Roadmap * Currently CPPBridge works only on MacOS , most likely on Linux too (because it uses the Unix architecture) but I will have to test it. Windows is coming next ASAP, since its my No1 platform for creating commercial games. Maybe establish a small protocol of communication via the Shared Memory , JSON looks like a good universal format *Thanks* Big thanks to Eliot for inspiring me and Esteban for helping me figure out things.

Nov. 8, 2016

Re: [Pharo-users] may I please be added to the Mercap/HighchartsSt repo

by Richard Pillar

Hi, This is great news. I have been using Highcharts for some of my personal projects and have added code to build box plots and heat charts. I will download the updates shortly. Many Thanks Richard On Mon, Nov 7, 2016 at 2:33 AM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > Paul, > > Quick comment: I was about to make an ANN soon but.... I have been > refactoring it a LOT these last days and I did: > > 1) make it fully the auto-generation code (already done) > 2) making it work for highcharts 5.0.2 (already done) > 3) start supporting highstocks (was going to start this this week). > > Please please please grab the very last version. What are your plans with > it? > > I just added you. > > Cbest > > > > On Sat, Nov 5, 2016 at 3:24 PM, PAUL DEBRUICKER <pdebruic(a)gmail.com> > wrote: > >> I'd like to add code that allows the creation of boxplots: >> >> http://www.highcharts.com/docs/chart-and-series-types/box-plot-series >> >> >> my username is pdebruic >> >> >> Thanks >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Nov. 8, 2016

Re: [Pharo-users] Spec: Setting rows height of a pictures list

by stepharo

Matteo your emails format looks quite strange... Le 8/11/16 Ã 14:27, Matteo via Pharo-users a Ã©crit : > I think the adaptor will called "MorphicImageFastTableAdaptor", and > the model "ImageFastTableAdapter". > > In the package "Spec-MorphicAdapters", the "MorphicFastTableAdapter" > uses an object "FTPluggableIconListMorphAdaptor". I would say yes because as you I find this suboptimal. Now may be it was created like that because of incompatibilities between uses of PluggableIconListMorph (RIP) and FT. Nothing is simple when you have legacy and different interaction protocol > > Could the "MorphicImageFastTableAdaptor" use directly a "FTTableMorph" > object, instead of creating "pluggable" adapter? Could you give a try and let us know. I' super hyper fuulllllll (tomorrow 6 hours teaching). > > cheers, > Matteo

Nov. 8, 2016