The Feenk team is working on on Diagrammer in Pharo. The idea is that developers should not have to leave the IDE - not even for drawing diagrams and they give a nice graphic preview on a more elaborate control of lines and figures in this tool with some screenshots on their twitter account.
– Diagrammer is a new engine for drawing diagrams based on Bloc. This is the first version, and we will continue working on it in the following weeks, so stay tuned for more news. This is also one of the first Bloc applications: https://twitter.com/feenkcom/status/972243179599794180
– Andrei put together a beautiful description of a scenario in which an application is molded interactively in the Playground & Inspector. The subject is face recognition, and the resulting code is both functional and explainable. This is intended as a tutorial material that shows what moldable development means and how it changes the way we program: https://twitter.com/feenkcom/status/972907051448979458
I pleased to announce you the first release of Cruiser: a tool to package your Pharo applications. The idea is to quickly convert an application from a development environment to a production one. A production environment means:
No writing on the disk
No access to the source code (by the shortcuts, debugger,…)
Recently I gave a demo at HPI on how I use the Cog VM simulator to step into machine code while simulating a Pharo image. Normally I like to do blog posts and I don’t like videos (videos take more time to do and I don’t like my French accent which makes them hard to follow), but it’s really difficult to explain what I am doing in this case without a video. Therefore I made a screencast where I show how I track down bugs in the Sista optimized code and how I debug them in the Cog VM simulator through machine code single stepping. If want to read a blog post on the VM simulator instead of a video you may want to look at one of my old blog posts here.
The video shows first how I build an image crashing at start-up on an optimized Sista method. Second, it shows how I simulate it with the VM simulator, including how I set different kinds of break point in machine code compilation and execution to track down where the problem comes from.
The image used for VM simulation can be built following those instructions.
I hope you will like the screen cast. Don’t hesitate to ask questions. Sorry for the French accent.
Thanks for Guillermo Polito we now have 64 bits support for OSSubprocess. You can see the required changes in this PR . I made a branch called `support64bits` so that you can help us test it even if CI said it was good . If you do test it and come back to us with the results, please tell us which OS you used.
Roadmap: Current release is v0.2.5. So I will let that release for Pharo <= 5.0. I will make a new release with the Pharo 64 bits and call it v0.3. That release should be used for Pharo 6.x. Once v0.3 is out, I will make a new release v0.4 with some changes I wanted to do since a loooong time and its a small refactor to minimize OSSubprocess dependency on OSProcesses primitives (at VM side). This is thanks to Holger Freyther and Alistair Grant . As that requires a new VM, then v0.4 should be used in Pharo >= 7.0.
I released yesterday SpecUIAddOns, a MIT library providing additional SPEC widgets not included in Pharo Smalltalk by default.
If you have any suggestions for how this package could be improved, please get in touch or suggest an improvement using the GitHub issues page. Installation, screenshot and usage instructions are provided in the GitHub page.
by Hernán (email@example.com) at March 06, 2018 03:43 AM
Guille is working on the Iceberg improvements and he wanted to be able to open a terminal window on top of the repository and interact with it via the command line. So we looked at this issue because I already in December made some experiments with the terminal emulation in Pharo.
In past, the Squeak had a working terminal emulation that used PseudoTTYPlugin. The VM is not built with this code for a long time but I tried to replace it with a small C library and then wrote an FFI interface to it. Together with that, I ported most of the old code Squeak code to Pharo.
With Guille we tried to avoid usage of such external library and wrote an FFI interface to all the required LibC functions. We were successful but we realized that there are several issues that are limiting us.
When you want to execute a separate process for the program that you want to open in terminal (typically the Bash), you need to redirect the standard IO files, create a fork of your process, do some additional initialization in it and call ‘exec’ on it. In the parent process, you change redirected IO files back to the original values.
But the problem is that between the FFI calls from Smalltalk the VM can do a lot of things including garbage collection etc. On OS X the fork() function has the following limitation described in man:
“There are limits to what you can do in the child process. To be totally safe you should restrict your yourself to only executing async-signal safe operations until such time as one of the exec functions is called. All APIs, including global data symbols, in any framework or library should be assumed to be unsafe after a fork() unless explicitly documented to be safe or async-signal safe. If you need to use these frameworks in the child process, you must exec. In this situation it is reasonable to exec your-self. yourself.”
As the result in most cases (but not all) the fork() and exec() pair from the Smalltalk side fails on OS X. Linux does not have this limitation however even there we found an issue. It is bound to the fact that fork() makes a fork of all the parent process that uses the same resources. As soon as Pharo is opened in a window and X11 is involved (the window wants to be repainted), it can lead to the VM crash.
So we learned that unfortunately we currently cannot use image-only FFI code for this task. We need a C library or VM plugin.
An SQLite extension is built as a .so/dylib/dll shared library file. Let's
use SQLite's rot13 extension as our example. The source file rot13.c is
located in the
SQLite source code's ext/misc directory.
To build the rot13 extension, also download the
amalgamation. Unzip the
amalgamation and copy rot13.c into its directory. Build the extension:
Verify that the extension works:
For use with Pharo, copy rot13.so into the Pharo VM directory where all the
other .so files are.
Next steps are done in Pharo. For the purpose of this blog post, I
downloaded a fresh Pharo 60536 64-bit image. Start the image and install
GlorpSQLite from the Catalog browser, which installs the latest
UDBC-SQLite. (This also installs Glorp, of course. If you run Glorp's unit
tests from Test Runner you should get all 890 tests passed.)
In a playground, run this snippet and Transcript should show, first, the
text "no such function: rot13" and then the rot13 outputs.
Note the messages #enableExtensions and #loadExtension:. For security
reasons, extension loading is disabled by default.