philippeback

First year I missed in due to my dad going under the knife on that very week end.

Nice to have the videos indeed!

I bet they will.

I walk slower because I have smaller legs.

Pff, but then I can swim faster than quite a lot of younger people, for longer, and daily.

And run.

WTF.

Same. No MBP for me, given the current sorry state of affairs.

shaders?

As a keyboard freak and vim user, I can relate.

As a Pharo contributor, well, there is indeed some clicking involved but not as much as you may think.

Keybindings are okayish at this point but can use some more love indeed. But this is not related to the core of Pharo but to the tooling that can be improved on some aspects (and this is moving forward actually).

If a user is not able to use a mouse, well, maybe the user can have a CI that integrates all of the code written in Tonel format and pushed to a git repo. Can work, Tonel format is pretty readable and usable from a command line.

There are ways to use Pharo as a "normal" language. But then, what's the point.

I am using Linux a ton (actually on clusters of boxes) and have a boatload of tools and languages (including low level C and in the past, assembly).

Now, I am also using Pharo to do things on Linux and it is easier and faster to get results out of it, especially when I need to fix a failure.

Pharo is not replacing the OS (even if it may feel like it).

One can deal with a running Pharo remotely (either via VNC directly into Pharo or with Pharo7, using Calypso remote connections).

I am with you on the symbolic aspect but still, having an image that one can inspect is great. I was not understanding its value when I started. Now, I do. And I also find it awesome to have a stacktrace saved to disk on a server so that I can reload it into my desktop box and see exactly where things went south, including variables, values etc. Try that with a core dump.

Now, to each its own and I have a personal little project I should actually deliver, namely being able to expose a fuse filesystem from a Pharo image, so that I can use vim and tmux and those things right from a server. There is no technical issue doing this, just damn code it.

The current Pharo is not an OS inside an OS. UnifiedFFI actually makes it easy to bind with C libraries (heck, I wrapped LibStrophe which is full of callbacks, callbacks that are actually written in Pharo, including full debugging on callbacks, see https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPj...) and the more Pharo evolves (been there since Pharo 2.0) the more it delivers on what I need.

With the new boostrapping, one can actually have images with just the bare minimum (no UI, no devtools) so that it can run.

Also there is lowcode, a way to do really fast stuff in Pharo (actually putting C types in there): https://hal.inria.fr/hal-01353884/document

What is also interesting for me in Pharo is that it actually stood the test of time. I am sick of new languages that pop up all the time, where one is relearning the basics with half baked libraries. Pharo core classes are solid, work well and after working in there for a while, it becomes second nature to do quite advanced stuff that one would not even dream to do in, say, Java.

Pharo is indeed a tool and in my toolbox, it is one the best ones so far. Coupled with Unix tools, it is a beast.

I not care if it is getting popular or not. What I care is that it works, that I can influence its course and change what is not pleasing me (try that with other toolchains).

And also that its community actually owns it, not a commercial organization like Oracle, Google, Microsoft... In that regard, Pharo is pretty much aligned on Linux.

The Pharo community understands the limitations or warts of Pharo, because there are some. But the features are currently delivering a net positive.

And, a little thing that is quite important: I have fun creating and maintaining systems I have done in Pharo.

This really contrasts with other solutions where fighting with accidental complexity takes 50% of the time, if not more.

Anyway, to each its own. I can relate to being angry when engineering. Pharo is lowering the level on my WTF-o-meter, which is actually good.

Amen a billion times to that. And then some.

Any feedback on how this went? The even sourcing pattern I mean.

The phone with 4G will not be subjected to stupid corporate firewall rules preventing access to, say, StackOverflow.

Looks like this in Win10:

https://imgur.com/a/X9PcgZe

Should be better anyway, but it is usable.

I already got it better but the VM has changed since and the rendering is not as good (but is faster for some reason).

Vs IntelliJ, it sucks a tad.

Because that bit indicates if it is a normal object or an integer (for 32 bit VM)

On the 64 bit VM, we can do better now on the integer front.

Floats are also boxed automagically in a 64-bit entry.

This would be a kind of REPL

https://github.com/guillep/Scale

"Scale aims to take Pharo into the shell. That is, to write shell scripts in Pharo, use its power, and have a better syntax instead of the ugly bash one"

There are a set of command line handlers that can be invoked and do eval or load code etc.

Current work ongoing on ClapSt, yet another command line handler. https://github.com/cdlm/clap-st

Test suites and test cases. Tests are usually written first and drive the development. When encountering a non existing message, the debugger pops up and asks you if you want to create the message.

Usually, this makes one think: "ha, this is not right" and then goes back on the execution stack and either fixes the test and continues or refactors something etc.

But in a dynamic language, tests are required to avoid regressions.

Programming as teaching goes both ways, programmer is teaching Smalltalk, Smalltalk helps in revealing thinking flaws to programmer. Loop continues.

Not true, I work on a 4K screen and it is clean. Win10 latest. Windows VM, some settings to tweak in Pharo but it works.

Upcoming is Bloc, which uses Mozilla2D as rendering engine and is vector based.

Next Pharo UI will use it.

See https://github.com/pharo-graphics/Bloc

One can save an image. I've done this thing https://github.com/Pharophile/HOImageSaver for example.

Nowadays, an image should not be considered as a long lived artifact, one would have a CI job to create the image. See https://github.com/hpi-swa/smalltalkCI

There is also Metacello with BaselineOf constructs etc.

Advantage is that when you get an exception, you just go back in the stack, fix, and then proceed forward instead of looking at a stacktrace and wondering what happened (yes, pdb is nice but not the same feel at all).

There are a things in it that are not in other Smalltalks (e.g. slots, revamped streams, GToolkit).

The point is to be a system to be improved over time.

Squeak is more conventional I'd say.

Yes, very true. And a system has a ton of interesting mechanisms.

Pharo now has pretty neat git support with Iceberg and Tonel file format.

I have been coding in Pharo while in BigScreen on a Rift. Cool experience. Better with the font size set to medium in Pharo settings.

The move makes sense. Cloudera has cash on board and Hortonworks has excellent technical chops and associated vision. The offering is not Hadoop only. Druid can be deployed with ease and Superset can hook into it nicely, all with proper metrics captured. Ambari is a wonderful single pane of glass to manage it all nicely. YARN is really good at managing capacity leveraging cgroups. Spark is one thing but far from the only thing. E.g.Flink. Hadoop3 introduces Docker containers right into YARN. It is all driven with JVM components, so security actually works. For all its limitations HDFS also has pretty cool powers. HBase is also a beast for a couple use cases. It is a versatile platform and is evolving well. Of course the learning curve is pretty steep. But payoffs are huge.

Hebdogiciel.... A fond!

In C# you have Winforms, WPF versions x,y, z.... and now UWA stuff.

And with Xamarin, a slew of other ways.

Not that less confusing.

You haven't been looking much then. http://gtoolkit.org

Try a become: in C#

There is room for all kinds indeed.

Yes, I'd like a cookie. But not for libgit, but libstrophe. It was easier (and clean!) to bind with Pharo than with a lot of other technologies. The ability to pin objects is also very usable.

I am busy with serious size Hadoop clusters as well, using a gazillion of technologies (including some Pharo on YARN mind you).

Nobody forces one to use Pharo and I actually find it indeed useful to have an FFI binding to libgit.

Pharo has had git support for years with git filetree. There is no urgent need for a built in tool. Iceberg is an integrated tool which is not even yet released for the version of Pharo it is intended for (7).

The project is useful to test drive UFFI significantly. As such it is a really good test bed for all kinds 7of data structures and callbacks etc. Coupled with the 64 bit VM + image it is even more so.

I am in the Pharo ecosystem as a long play. Expedient solutions are plentiful. But they all lack this QWAN in Pharo that makes it enjoyable to me.

I am interested in understanding how things do work. Pharo allows me to do it in a way that suits me.

Given the count of "me" above, it is clear that I follow my own path and I couldn't care less about popularity.

Truth be told, I find it somewhat useful to have a harder to approach community. It keeps the signal to npise ratio at an acceptable level.

I am also using Tmux and Vi an awful lot.

And working on a fuse thing that exposes my running image as a filesystem so that I can such tools as well.

But saying that the tools are different and you cannot be bothered to use them? Look, Visual Studio is a monster beast, with tons and tons of features, including Azure ones. It takes a serious while to master.

And vim also takes a serious while to use well. Especially when we use a couple of plugins.

An engineer knows the tools. Then a specialist masters them. The master makes them. Or changes them.

Pharo allows one to do that. Without strings attached.

Come on, you are just throwing mud around for some reason I do not even want to know about.

It is hard to lose code with Pharo. I have always recovered everything 99.999% of the time.

You are happy with VW, fine with me. I cannot stand it.

From what I read on your project, it was quite daring to expose you to Bloc and Iceberg and the latest Pharo.

I wouldn't have.

Because these things are still in flux.

These things are interesting and are the way forward. But not ready for end users.

But this has exposed you to the realities of creating new things: it is not as clean as one would want nor are users that cool when facing them. In a unusual environment like Pharo, it gives a kind of blurring effect since a user has a hard time distinguishing between solid ground and treacherous new terrain.

I would advise you to look back at Bloc and Iceberg when Pharo 7 is released.

The occasionnal freeze of the environment is indeed a pain and a new user would cringe more than once. I actually have a REPL server running in my images to restart the UI when such stuff occurs. Not the realm of a newcomer for sure.

Pharo is great for my uses. It is not the best tool for everything, granted. But when dealing with complex domains, I haven't found anything close.