I announce the availability of Smallapack in Pharo6.
The ConfigurationOfSmallapack is in
http://www.squeaksource.com/MetacelloRepository and there is a copy in metarepo for Pharo 3/4/5/6.
Currently, the ported version uses a derivative of OpalCompiler patched to handle method with 16+ arguments.
External function calls have not been converted yet to UnifiedFFI, but the patched compiler rather has hook to compile legacy FFI.
Though I did not install the hook to call FFI with more than 15 arguments, so there is at least 1 unit test failing (but not crashing).
I have auto-re-generated all the source code for using UnifiedFFI formats, so the dependency on legacy FFI is not a necessity (apart for simplifying cross dialect maintenance).
But I want to review the generated code method by method rather than filing it in blindly (the wrapper functions are also generated, and I might loose comments or improvments if I'm careless). Unfortunately, the state of diff tools in Pharo6, be it thru MC or worse than all, thru legacy change lists, does not enable such a large scale review, so I think that I will edit in Squeak and run in Pharo...
Now that Smallapack supports Opal, there should be no major problem for porting to Pharo7, but I did not have time to try yet. A few more MC regressions, and the fact to forbid protocol beginning with a * was too serious a cross compatibility hurdle for me. But I'll come back to it, tools are generally better in ph7 than ph6. Stay tuned.
We have been using this week with Pablo a combination of Visual Studio Code, cygwin, and gdb to build and debug the VM to chase some issues during ffi calls in win64.
It was overall simple to setup, and though I thought it was going to be just a text editor with vitamines, it ended up being a really light but versatile IDE with code navigation, compilation and debugging integration.
But, since there were some little things over here and there like gdb
source code mapping that was not so straight forward to find in the
documentation, we thought it would be good to share it.
If somebody is interested in using a similar setup to work with the VM, I've left my configuration files in the following gist, including:
- cygwin bash terminal integration (also with zsh, but that's pure cygwin)
- task actions to build cog and stack vms on debug mode
- launch configs to run both in debug mode with gdb attached
Guille & Pablo
I am happy to annoyance a new channel in our Discord Server , #news
News is a read only channel (members cannot post there only admins) that I
intended to act as a newspaper of short that you can read with your morning
coffee to get all the latest news in the Pharo land.
The rules of the channel are very simple,
1) Only admins can post there. Its not a dicussion channel, all other
relevant channels can be used for discussing the Pharo news. We already
have tons of them.
2) every post must be no more than 2 lines, similarly to twitter, this is
for headlines not for entire articles
3) every post must contain a link for more info
4) every post must mention the author that the news concern
5) least news must always be related to Pharo, it can be anything
(article, project, update etc)
6) last but not least I am always open to suggestions in case something
escapes my attention
If you have not done so make sure you join our Discord server following
You wont be getting only news but a very active community always willing to
help you with any questions and problems you may have, real time.
All people are welcomed :)
What sweet nothing does the title refers to? It could be about null, but it in fact will say nothing about that. The nothing in question is whitespace in program text. Specifically, whether whitespace should be significant in a programming language.
My instinct has always been that it should not. Sadly, there are always foolish souls who will not accept my instinct as definitive evidence, and so one must stoop to logical arguments instead.
Significant whitespace, by definition, places the burden of formatting on the programmer. In return, it can be leveraged to reduce syntactic noise such as semicolons and matching braces. The alleged benefit is that in practice, programmers often deal with both formatting and syntactic noise, so eliminating one of the two is a win.
However, this only holds in a world without civilized tooling, which in turn may explain the fondness for significant whitespace, as civilized tooling (and anything civilized, really), is scarce. Once you assume proper tooling support, a live pretty printer can deal with formatting as you type, so there is no reason for you to be troubled by formatting. So now you have a choice between two inconveniences. Either:
You use classical syntax, and programmers learn where to put the semicolons and braces, and stop worrying about formatting, Or
You make whitespace significant, cleanup the syntax, and have programmers take care of the formatting.
At this point, you might say this a matter of personal preference, and can devolve into the kind of religious argument we all know and love. To tip the scales, pray consider the line of reasoning below. I don’t recall encountering it before which is what motivated this post.
In the absence of significant whitespace, a pretty printing (aka code formatting) is an orthogonal concern. We can choose whatever pretty printing style we like and implement a tool to enforce it. Such a pretty-printer/code-formatter can be freely composed with any code source we have - a programmer typing into an editor, an old repository, and most importantly, other tools that spit out code - whether they transpile into our language or generate code in some other way.
Once whitespace is significant, all those code sources have to be cognizant of formatting. The tool writer has to be worried about both syntax and formatting, whereas before only syntax was a concern.
You might argue that the whitespace is just another form of syntax; the problem is that it is not always context-free syntax. For example, using indentation to nest constructs is context sensitive, as the number of spaces/tabs (or backspaces/backtabs) depends on context.
In short, significant whitespace (or at least significant indentation) is a tax on tooling. Taxing tooling not only wastes the time and energy of tool builders - it discourages tooling altogether. And so, rather than foist significant whitespace on a language, think in terms of a broader system which includes tools. Provide a pretty printer with your language (like in Go). Ideally, there's a version of the pretty printer that live edits your code as you type.
As a bonus, all the endless discussions about formatting Go away, as the designers of Go have noted. Sometimes the best way to address a problem is to define it away.
There. That was mercifully brief, right? Nothing to it.
by Gilad Bracha (email@example.com) at January 12, 2019 07:05 PM
I created a new release of P3, the modern, lean and mean PostgreSQL client for Pharo.
Version 1.1 contains the following changes:
- added support for Postgres Extended Query protocol (P3PreparedStatement) (thx Jan @jvdsandt)
- added support for reading array type values (currently INTEGER FLOAT BOOLEAN TEXT VARCHAR)
- added P3-Tests package and moved all tests there
- more comments
- more unit tests
Especially Jan's contribution adds a lot of functionality: the ability to work with prepared statements.
Here is an example doing a batch insert of 100 records (which is more efficient).
| client statement |
client := P3Client url: 'psql://sven@localhost'.
client execute: 'DROP TABLE IF EXISTS table1'.
client execute: 'CREATE TABLE table1 (id SERIAL PRIMARY KEY, created_at TIMESTAMP DEFAULT NOW(), name TEXT)'.
statement := client prepare: 'INSERT INTO table1 (name) VALUES ($1)'.
statement executeBatch: ((1 to: 100) collect: [ :index | Array with: ('Text #', index printString) ]).
client query: 'SELECT * FROM table1'.
client execute: 'DROP TABLE table1'.
Season's Greetings to you all.
I've modified PostgresV3 to do parameter binding, i.e., parsing SQL and
binding/executing with data are performed in separate protocol steps.
I've add a simple client API with some examples demonstrating usage. The
examples require a PostgreSQL server loaded with the Sakila database.
Instructions on bringing the database up and running the examples are in
my blog post:
Last month Amazon extended their serverless runtime platform AWS Lambda with support for custom runtimes. I created a Pharo Lambda Runtime so now we can implement Lambda functions in Smalltalk and easily deploy them on the Lambda platform.
Lamba has quite a large “free-tier”, more than enough to do some experiments and to host small applications for free.
As part of our constant try to enhance process, we are moving the issue tracker to GitHub.
You can now declare issues here:
Q: Why we do this?
- Because reuniting all development process in just one point will enhance traceability
- … and communication (there are a lot of conversations that now happens in different places (list, issue, PR). With this move we put issue and PR discussion in same place.
- … and people historically has complained that “they need to log to fogbugz to just see the issues”
- … and this allows us to decommission one server we have now just to get the issues names when creating branches (and before slides).
Q: Does that means fogbugz is bad?
A: Not at all! It is a great tool and we are very grateful of it. Is just that we want to reunite our communication into a single point.
Q: What will happen with issues reported in FogBugz?
A: Pharo 7.0 issues will be taken as before. Pharo 8.0 issues need to be re-opened in GitHub. There are less than 25 right now and we ask people reporting it to move them again (maybe we would do it, but better is owners do).
Q: How can we “branch from issue” now if we do not have FogBugz?
A: We already added a tool “branch from issue” that uses GitHub issue tracker. This will be the same as before.
And for the same price, we add that option to other projects: All GitHub projects now can benefit from “branch from issue” functionality.
We are preparing to release Pharo 7.0 (which will be in January, as soon as we finish some last details). And in the meantime impatient people has asked (and obtained) the aperture of Pharo 8.0 development! So you now can start making Pull Requests against Pharo8.0 branch
PostgresV3 is a pure Smalltalk
implementation of the PostgreSQL v3 wire protocol. I've modified
PostgresV3-Core to do parameter binding and added PostgresV3-DBAPI, a very
simple client API.
In PostgresV3-DBAPI, there are a number of examples in PG3ExampleClient.
These examples require a PostgreSQL server loaded with the Sakila database.
To set that up, firstly, download the
Sakila database files.
Place the PostgreSQL files in ~/data, say.
The quickest way to get PostgreSQL up and running is by Docker. Here's my
docker-compose file that uses the official Postgres-11 image. Data is kept
in a separate volume 'pgdata'.
Bring up PostgreSQL, create roles, load the Sakila data, assign
In a fresh Squeak image - I'm using 5.2 - evaluate in a workspace:
In a fresh Pharo image - I'm using the latest 7.0 pre-release - evaluate in
As this is a pure Smalltalk implementation, it should also work in earlier
versions of Squeak and Pharo.
This email to announce that a new minor release of PetitParser (1) has been published on GitHub (v2.1.0).
Here is the change log:
- Each package has its tests separated in a separated package.
- Cleaned baseline, made it more modular.
- Created more groups to let people load the part of the project they want.
- Some cleaning in `PetitParser` package.
- Integrated PetitPreprocessor and PetitParserExtensions in the project as separated groups
#31 Extract PPTextHighlighter into a separated package.
#21 Add contribution guidelines
#13 Update README with new groups
#9 Fix CI configuration
#19 A TODO comment in PPMemoizedParser>>#parseOn: might need to be fixed cleaning
#11 Inconsistent method classification
#15 Split tests in their own packages cleaning
#22 PetitPreprocessor is missing some extensions
#3 Use `>>>` notation for examples inside method
#8 PPStream>>#column: has commented code that should be removed
#7 PPCharSetPredicate and PPContextMemento need to be commented
#1 Replace 'Oops' error message with a meaningful message
#4 PPContext>>#on:stream: should be removed
#2 Integrate PetitParserExtensions package from Smalltalkhub
#5 Integrate PetitPreprocessor package from Smalltalkhub
Thanks to Cyril Ferlicot for his help.
If anyone is interested, I've created the beginnings of a library for
handling coordinates at: https://github.com/akgrant43/GeoSphere
- Parses string coordinates
- Calculates the distance between coordinates
- Opens a web browser in OpenStreetMap at the receiver's coordinates
Examples of string formats that can be parsed:
- 144.61025 @ -38.28697
- 38° 17′ 13.09″ S, 144° 36′ 36.9″ E
- 38 deg 17' 13.09" S, 144 deg 36' 36.9" E
The distance calculation uses haversine (assumes the earth is a
sphere), which is good enough for my needs at the moment.
Thanks again to Sven, Benoit, Pierce and Richard for their input.
Maizo is aimed toward molecular- and reaction discovery based on big data of quantum mechanical global reaction route mappings. The global reaction data includes equilibrium structures (EQs), dissociation channels (DCs), and transition structures (TSs), which are automatically calculated by a global search on a potential energy surface using the GRRM (global reaction route mapping) method. Applications to molecular- and synthesis design are an important part of the project. Machine learning and visualization techniques as well as chemoinformatics methods are essential to acquire useful information from the large reaction data space. The team developed an RMapViewer, which was developed to visualize and analyze the GRRM outputs.
he mentions that Pharo is not reproducible and can not be bootstrapped from its own source code
it is not easy for beginners to follow Pharo
The first point is actually invalid. Konrad seem to have missed that Pharo since two years IS ACTUALLY BOOTSTRAPPED - so we can build a image from scratch and from our own source code. This is actualy in place and used to build Pharo now. Even smaller images (like the minimal one) beside what is provided in the default Pharo download.
For the second point I agree as Pharo is moving fast it might not be easy to follow. Also the community is small. Due to this we can not invest our sparce resources into making things easy for newbees - but rather will continue to focus on moving forward. Especially with the upcoming Pharo 7 including better git support and the new Calypso browser many things have changed compared to Pharo 6.
But there are books available and there is the mailinglists as well as the Discord chat to ask questions and get answers. Situation is far better than in 1994 when I dived into Smalltalk and where it was not easy to get informations or even a free system to enjoy the openess and productivity of such a system.
Nonetheless - as one of the primary contributors of the Pharo project I really enjoy such blog posts. It shows we are on the right track. There is still a long way to go - but step by step it goes...
by Torsten (firstname.lastname@example.org) at December 19, 2018 11:30 AM