November 2016 - Pharo-users

Re: [Pharo-users] MOOC TOC cleanup

by Siemen Baader

Hi Stef, I have cloned the repository and linked the slides directly from the TOC. I also have styled it with Bootstrap labels and glyphicons, and added anchors to every item to make them easily linkable, eg for discussions on the mailing list / slack. The HTML files for the exercises refer to the directory 'support' ( http://rmod-pharo-mooc.lille.inria.fr/MOOC/support ) for css and js files. I think you have missed to put the directory on the server, the links are broken. Can you upload it? As for the videos, they require some sort of aggregation of subtitles and video, either in a separate HTML file with <video> tags, or eg. on youtube. At some point during or after the MOOC I remember the videos were in fact on youtube, with subtitles. Now they are back in the custom made player on fun-mooc.fr, which is a bit impractical because the subtitles are on the right side, slightly out of view when attending to the lecture. Are the videos still on youtube? I could not find them again. Would you prefer a 'full', downloadable solution with the videos and subtitles all on mooc.pharo.org? It would be relatively easy to script something that generates the html files, but it would take more time than linking to the youtube videos, and I think the playback experience on youtube would actually be better / more cross-platform. I have a put up a preview on https://siemenbaader.github.io/PharoMooc-website/. What do you think? best, Siemen On Thu, Nov 3, 2016 at 6:31 PM, stepharo <stepharo(a)free.fr> wrote: > > > Le 3/11/16 Ã 18:05, Siemen Baader a Ã©crit : > > Hi Stef, > > Sure. >> Let me know how I can help. >> I will forward your mail to christelle that manages the mooc for us >> > > Thanks. I'm looking forward to hear from her. > > She translated the page but she is busy I forwarded the email to you. > > > >> Siemen >> did you see the web portal >> http://rmod-pharo-mooc.lille.inria.fr/MOOC/WebPortal/co/pharo.html (we >> should add a pointer from http://mooc.pharo.org to it) >> and also the http://mooc.pharo.org page? because we have the full >> control on this one. >> And this is on my todo to make sure that people can get an archive with >> the complete mooc nicely packaged. >> Now if you want to help it would be great. >> > > Sure, we could either do it at fun-mooc.fr or mooc.pharo.org. The latter > is cleaner and open to all. How do you generate it, and where is the > source? I'd like to have a look. > > The source is on github. > https://github.com/SquareBracketAssociates/PharoMooc-website > > What is the role of WebPortal? > > the idea was to propose a package to user and we were paid and forced to > use this format. > I would prefer plain HTML (or even pillar). > > > best, > Siemen > > > ------------------------------ > View this message in context: Re: MOOC TOC cleanup > <http://forum.world.st/MOOC-TOC-cleanup-tp4921304p4921361.html> > Sent from the Pharo Smalltalk Users mailing list archive > <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at Nabble.com. > > >

Nov. 10, 2016

Re: [Pharo-users] about balkanisation

by Dale Henrichs

On 11/8/16 11:04 PM, Igor Stasenko wrote: > > > On 7 November 2016 at 14:28, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > > [ ... ] >> >> And this one I don't understand. A smooth, git / iceberg oriented >> transition over Monticello/Metacello is perfectly doable... As >> Dale explained. A nice Iceberg gui reworking / making git usable >> is perfect. >> >> But why make the transition so hard? You get Stef angry on a >> Sunday morning because he can't find things anymore... even if he >> is a strong proponent of the strategy he complains about ;) > > No my point was not that. > My point is that it is important to pay attention and not to add > more noise than necessary. Let us take the time and move alltogether. > > If you want to get somewhere with this story, you don't want to wait > till everything will be ready. > Transition will never start unless you force users to enter the > minefield and let them clear the mines for you. Step by step. Many > will blow themselves up, while some will manage to pass unhurt.. > Because else, it will be always a minefield between you and the > destination of your journey :) I think that at the early stages of the transition you have to support both approaches ... when the new tools are in place and stabilized then one can consider ... the transition has already started so this is not a case where you need to force folks to change, but a case where you need to support the folks who choose to change ... it can be relatively low cost to keep the old tools around for quite awhile ... I would think ... Dale

Nov. 10, 2016

Re: [Pharo-users] about balkanisation

by Dale Henrichs

On 11/8/16 7:09 AM, Thierry Goubier wrote: > Hi Dale, > > 2016-11-08 2:03 GMT+01:00 Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>>: > > [ snip ... ] > > > yes I think this is the area where a Metallo Project Browser comes > into play. The technology for committing the dirty packages in a a > ConfigurationOf has been around for quite awhile, but a tool that > unifies the "multi-package" commit for ConfigurationOf and > BaselineOf hasn't popped out of the wood work ... > > > I'm having some issues with the scripting approach of Metacello, for > that. Just manipulating a baseline in the Metacello registry (locking > it) seems to be like writing a compiler code generation item: write a > Metacello script ;) (Metacello>>#lock contains interesting code). I think I agree:) ... that is why i am talking about a tool ... developers shouldn't have to pass around workspaces to load and manipulate projects .. a project tool can partially automate the process, but I believe that there needs to be a "load spec" object that can be passed around and massaged by code instead of requiring a user to edit a Smalltalk workspace ... it's what I do in tODE ... the only times I have to write Smalltalk load scripts is when I work in Pharo :) I will repeat that I don't think Pharo should do exactly what I've done with tODE, but a Metacello Project Browser and some sort of "load spec" object that is shared amongst a cluster of images is something that needs to be seriously considered ... > > >> >> What is a bit annoying, really, is this talk of rewriting >> everything where some of the pieces (the project browsing you're >> talkin about, for example) is already there in the image, just >> not exposed. > Well I am annoyed as well .. I would say that perhaps we are in > screaming agreement ... I've said that I don't think it's a lot of > work to do the project-centric tool. but a project-centric tool > that encompasses both ConfigurationOf and BaselineOf will expose > the features that "are already there" >> >> I'm trying to code a little something for that... stay tuned for >> a screenshot soon. > Cool:) > > > And here it is! I'm still fighting with the Metacello lock / unlock thing. > > Images intÃ©grÃ©es 1 > > If Pharo was more really modular in configurations and baselines, then > I would see more things into the registry and I could group packages > based on that (instead of having to prepare a ad-hoc classification > for my my browser). Yes this is headed in the right direction ... I am in Argentina this week so it isn't easy for me to do much collaboration, but I would love to help you with your lock problem next week ... For example ... you do not want to directly expose the Metacello registry as there are "hybrid projects" where a ConfigurationOf causes a BaselineOf to be loaded, so the BaselineOf needs to take precedence (I have code for resolving this) and I strongly suggest that the Project Browser not be built-into the Class Browser, but be a separate tool like the CataLogBrowser ... but this is just a suggestion --- a separate tool dedicated only to loaded Projects and unloaded Projects of interest allows one to get a very quick overview of what is in the project or not and when version skew pops up, one can easily see the affected projects ... embedding this kind of information in the code browser can make it hard to get the overview and if you choose to live with version skew can be annoying to ignore .... again these are just my thoughts .. Regardless I think you are definitely headed in the right direction and it isn't all that much work ... yet:) Dale

Nov. 10, 2016

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

by Igor Stasenko

On 9 November 2016 at 08:41, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > I am the only potential customer of CPPBridge because > > a) I am the only C++ coder AFAIK > b) Using DLLs (dynamically linked shared libraries) is still by far the > best solution because using the UFFI you can do everything from Pharo. > Compared to CPPBridge which you will need to code in C++. > > So as you can imagine making a general library for IPC communication via > shared memory is not my goal. > > The Unreal part will be a separate library that will depend on this one. I > have not touched that one yet but I will soon. > > UnrealBridge library will become my most important Pharo project because > the goal is to start selling games using Pharo and Unreal. > > IPC Protocol wise , I don't think synchronisation will be an issue because > Unreal will be too fast for Pharo anyway and its ok if Pharo lags behind > even a few dozens of milliseconds which is a matter of losing a couple of > frames. I may implement a hybrid synchronisation for when Pharo lag becomes > too severe but that will have and see in practice. > > Something that interest me is "stealing" your idea for NBOpenGL where you > made an automatic generator for the library that used OpenGL headers. This > is something that could benefit me a lot because Unreal contains over > 10.000 methods and wrapping them one by one is not something I am looking > forward to doing. This means generating both C++ and Pharo code. > > Well, a while before that, i wrote own lobotomized smalltalk implementation in C and started generating bindings to Ogre3D engine. I even had certain success with it, but then i started grand-rewriting of VM and abandoned it. That was before i switched to Squeak, then Pharo. So, your incentives quite familiar to me :) I was quite fun journey, and i learned a lot while doing it.. especially about smalltalk. Of course if I feel that what I implement with UnrealBridge is general > purpose enough I can port it back to CPPBridge. > > In any case I must say it was a lot of fun accomplishing this goal and > cant wait to dive deeper into IPC magic, making Pharo the nerve centre, the > brain , of my coding environment is a role that I think Pharo would excel > at. It will also allow me to use Pharo as much as possible and provide a > super powerful game / graphics engine to the Pharo community. Shared memory > is that just the means to that goal. > > Moose could also a play role later on for analysing my game code both in > Pharo and C++ and use Roassal for some nifty visualizations though I could > use Unreal as backend to Roassal for some nice 3d visualisations. > > So ton of ideas, tons of fun and a ton of time to accomplish them. > > PS: I have to say you have been inspiration for my IPC saga, you did the > unthinkable (at least to me) and brought Assembly to Pharo, I never had a > use for Assembly but nonetheless you taught me that Pharo potential is more > massive than I imagined, so thank you :) > I don't understand why people find assembly scary or mind-boggling? I dived into assembly few months after i learned my first programming language, it was Zilog 8-bit CPU. A marvelous gem :) And this was always fascinating to feel that you can control the computer's behaviour down to a tiniest detail. We were even researching what certain i/o ports and interrupts were responsible for by setting different bits/bytes here and there and see what happen. Because if you don't understand something down to the tiniest detail - you cannot be sure that what you doing will work, or work optimally. So i find it frustrating that most of programmers don't know and not even thinking about touching assembly. Because it very simple, straightforward and megalomaniac-rewarding :) -- Best regards, Igor Stasenko.

Nov. 10, 2016

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

by Igor Stasenko

On 9 November 2016 at 07:49, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Not in C but there std::string in C++ similar to our String object. > > Strictly speaking , std::string is again not part of C++ per se, it comes from library that implements such class. > C char indeed is more a byte array than a string. Actually C won't allow > to change the string value mainly because it thinks you try to change the > size which something that is not allowed for arrays anyway, so the only way > to change a char string aka char array is character by character. > > Null termination is why I filled the shared memory with zeros to be on the > safe side and then added the string and the number on top > > just wanted to warn you, to make sure you understand that char[100] is not string, not in C , not in C++. And, of course, it should not autoconvert to smalltalk String object(s) in FFI, because many C coders use 'char' as a default data type to operate with buffers of certain length and to count their size in bytes. > On Wed, 9 Nov 2016 at 03:41, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> 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. >> > -- Best regards, Igor Stasenko.

Nov. 10, 2016

Re: [Pharo-users] Ideas for a binary format for an image acting as an extension of the Pharo image

by Dimitris Chloupis

Nice idea I will forward to VM mailing list On Thu, 10 Nov 2016 at 00:29, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > How about using the binary format of the VM itself? Itâs a tested format > that gives you instant compatibility with Pharo. I guess the VM people have > documentation for it and could give you some pointers. > > -- > Does this mail seem too brief? Sorry for that, I donât mean to be rude! > Please see http://emailcharter.org . > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University > of Chile > > On 09 Nov 2016, at 17:27, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > So now that CPPBridge at least basic are sort out I have to figure out a > binary file format > > The idea here is to implement an image format which will be part of the > memory of the Pharo process but will live outside the memory of the Pharo > VM. Lets call this CPPMemory will be stored to an image file, lets call it > CPPImage, like we do with the Pharo image and will store a shared state > among all other processes (Pharo or not) that connect to this shared memory > (CPPMemory) via accessing the file (CPPImage). So basically it will act as > an extension to the Pharo image. > > In the image file , objects will be stored obviously not in a byte-code > format but definitely in a byte format that will basically store the data > of this object using very basic primitives like character , integers and of > course bytes. > > Obviously each object will have to have an id as a header and also its > size in bytes and the size of each of its instance variables. > > There will be also a global headers for the entire file with the list of > the objects included and probably a references to other CPP images that > they will be able to interconnect with each other like lego blocks. > > Thats my vague idea, but I am open to suggestions and even links to > articles and documentation about what a binary format must have to be > considered well architectured. Obviously I dont expect perfection because > this is my first binary file format but at least I am looking for advise > for avoiding common pitfalls. > > >

Nov. 9, 2016

Re: [Pharo-users] Ideas for a binary format for an image acting as an extension of the Pharo image

by Johan Fabry

How about using the binary format of the VM itself? Itâs a tested format that gives you instant compatibility with Pharo. I guess the VM people have documentation for it and could give you some pointers. -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org <http://emailcharter.org/> . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On 09 Nov 2016, at 17:27, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > So now that CPPBridge at least basic are sort out I have to figure out a binary file format > > The idea here is to implement an image format which will be part of the memory of the Pharo process but will live outside the memory of the Pharo VM. Lets call this CPPMemory will be stored to an image file, lets call it CPPImage, like we do with the Pharo image and will store a shared state among all other processes (Pharo or not) that connect to this shared memory (CPPMemory) via accessing the file (CPPImage). So basically it will act as an extension to the Pharo image. > > In the image file , objects will be stored obviously not in a byte-code format but definitely in a byte format that will basically store the data of this object using very basic primitives like character , integers and of course bytes. > > Obviously each object will have to have an id as a header and also its size in bytes and the size of each of its instance variables. > > There will be also a global headers for the entire file with the list of the objects included and probably a references to other CPP images that they will be able to interconnect with each other like lego blocks. > > Thats my vague idea, but I am open to suggestions and even links to articles and documentation about what a binary format must have to be considered well architectured. Obviously I dont expect perfection because this is my first binary file format but at least I am looking for advise for avoiding common pitfalls.

Nov. 9, 2016

Ideas for a binary format for an image acting as an extension of the Pharo image

by Dimitris Chloupis

So now that CPPBridge at least basic are sort out I have to figure out a binary file format The idea here is to implement an image format which will be part of the memory of the Pharo process but will live outside the memory of the Pharo VM. Lets call this CPPMemory will be stored to an image file, lets call it CPPImage, like we do with the Pharo image and will store a shared state among all other processes (Pharo or not) that connect to this shared memory (CPPMemory) via accessing the file (CPPImage). So basically it will act as an extension to the Pharo image. In the image file , objects will be stored obviously not in a byte-code format but definitely in a byte format that will basically store the data of this object using very basic primitives like character , integers and of course bytes. Obviously each object will have to have an id as a header and also its size in bytes and the size of each of its instance variables. There will be also a global headers for the entire file with the list of the objects included and probably a references to other CPP images that they will be able to interconnect with each other like lego blocks. Thats my vague idea, but I am open to suggestions and even links to articles and documentation about what a binary format must have to be considered well architectured. Obviously I dont expect perfection because this is my first binary file format but at least I am looking for advise for avoiding common pitfalls.

Nov. 9, 2016

connecting to remote pharo 5 image on server.

by itay yahalom

Hi all, is there any RFB or VNC to use with pharo 5? i want to connect to my pharo 5 environment remotly, the image sit on a linux server that is hosted on digital-ocean . all of this is so i can control and see if something go bad with the image (and debug it) or that i can use pharo to check the mongodb data. any help will be great . itay.

Nov. 9, 2016

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

by Dimitris Chloupis

Ok documentation has improved a lot , it should be more obvious now https://kilon.github.io/CPPBridge/ Any comment , critic more than welcomed :) On Wed, Nov 9, 2016 at 1:10 PM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > I would not call you lazy, its normal to want to see documentation before > installing something and at least an example. Actually thats a good idea, I > will add a few more comments in the example and use it on repo's front > page. > > On Wed, Nov 9, 2016 at 12:56 PM Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > > 2016-11-09 11:41 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > > "Hi. > > It would be nice to see simple code (not in video) how to create memory > and read/write data to it." > > If you get the Project it comes with an example how to use in the class > side of the CPPBridge Class and its in methods retrieveSharedValueStep1 and > retrieveSharedValueStep2 > > > I just a lazy guy. Thank's for pointing code here. > >

Nov. 9, 2016