Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Dimitris Chloupis]

"Abusing an external text editor is a slap in the face of anyone building
good tooling support into Smalltalk over many years.
I know Dimitris tried to help people (as often) - but I guess this video
really gives a false impression and guides people the wrong way."

Abusing ? Wait what on earth you talking about ?
How is using an external editor , abusing ?
Who is all mighty authority that says all these things ?
Is there a coder out there that can predict the needs and preferences of
every single coder ?
Last time I checked we edit text inside pharo , not bytecode.
Since when Smalltlak was not about source code, since when Smalltalk is not
about text ?
Oh sorry I forgot Pharo is not Smalltalk.

Yeah I guess I have never been religiously enslaved to any ideology or
belief and is true I do guide people the wrong way instead of taking
something at face value, because some authority says so, to use their
critical thinking and learn from their mistakes.

Yeah I guess my slap in the face of people build good tooling , is a stream
of videos that took me hours and hours to produce, that take newcomers by
hand and teach them step by step how to make tools in Pharo. Or
contributing to documentation because apparently building a good tooling
will magically transmit the knowledge to user heads.

My video is a problem and is not a problem that our documentation is still
lagging behind even when the most basic book is concerned Pharo By Example ?
My video is a problem and is not a problem that the vast majority of the
code inside Pharo does not even have class comments ?
My video is a problem and is not a problem that the image has been ridden
with feature creep and accumulating complexity that serves no purpose ?
My video is a problem and is not a problem that every time we talk about
new technologies everything , we have to be informed again and again
absolutely everything is inferior to Smalltalk ?
My video is a problem and is not a problem that every time one dares to
criticize Pharo or Smalltalk apparently we do not understand Smalltalk
while they understand other technologies ?

But worry not, the chances of me posting another video which were already
extremely low have certainly reached absolute zero.

I was planning to integrated an IPFS like system using bittorent protocol
inside Pharo so I can interconnect images of our entire community into one
universal virtual p2p image as a proof of concept for a commercial project
I am developing for Blender. Main use there will be to unify asset
management and code distribution in an image like fashion like happens in
Pharo.

https://ipfs.io/

But I guess this is also inferior to Smalltalk standards and a slap in the
face of anyone making good tooling in Pharo.

My hand got tired of slapping, I think I will take a break.


On Sat, Jan 26, 2019 at 10:10 AM Esteban Lorenzano 
wrote:

>
>
> > On 25 Jan 2019, at 20:52, Torsten Bergmann  wrote:
> >
> > Hi,
> >
> > Maybe Pharo's switch to Tonel remind people now on Java or C# class
> files and thats why they ask for the "traditional editing”.
>
> Nah, people talk about this time to time.
> Tonel format is just a readable format that yes, cool be used to edit in
> text files (but that was doable with chunk format too).
>
> For all the rest, +1 :)
>
> > But remember that Kent Beck once said: "I mean, source code in files;
> how quaint, how seventies!". Tonel is a readable storage format,
> > you could have the source code even in a database (with an ENVY and
> STORE like approach)
> >
> > And ouch  that video really hurts and I think it will be more
> disturbing than helpful especially to many newbees
> > now trying to use their favourite text editor for Pharo coding instead
> of really learning about a very flexible IDE and workflow with
> > browsing, interactively inspecting and refactorings.
> >
> > Abusing an external text editor is a slap in the face of anyone building
> good tooling support into Smalltalk over many years.
> > I know Dimitris tried to help people (as often) - but I guess this video
> really gives a false impression and guides people the wrong way.
> >
> > Sorry - but I'm reminded on pictures like this:
> >
> >
> https://i1.wp.com/ecbiz168.inmotionhosting.com/~perfor21/performancemanagementcompanyblog.com/wp-content/uploads/2012/05/magnet-image-sws-one-no-border.gif
> >
> > Dont get me wrong: VisualStudio/VisualStudio Code, Eclipse, IntelliJ and
> others are nice, I use them too for other languages or tasks. Nicely done -
> but still
> > too static. Often I wished only half of the money invested into such
> IDE's could have been spend on better Smalltalk tooling.
> >
> > Remember: once VisualAge for Java got a price as the first usuable Java
> IDE (when people used Notepad to write *.java files) - but underneath it was
> > fully coded in Smalltalk and the Java debugger was the Smalltalk
> debugger running the java subset of bytecodes. At that time VisualAge for
> Smalltalk
> > was the base for the full 

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Dimitris Chloupis]

I think you got this the wrong way

Sure emacs and vim are very popular when compared to Pharo.
When compared to IDEs oh boy , that's another story.
There is a reason why their hardcore user are so desperate to call them
IDEs and is not because they like IDEs, they dont.
They hate IDEs.

Text based coding, has lost  no my bad , let me correct this, text
coding never stood chance. Smalltalk was like a nuclear bomb that when it
landed it left nothing in its path,
There is no doubt that nowdays IDEs dominating to a vast degree. Obviously
big guns on top are Visual Studio (not Code) and Xcode by far for obvious
reasons.

Even in the case of my favorite IDE , Delphii its really amazing that even
though its company has long disappeared, the all mighty Borland which one
was the equivalent of Sun/Oracle.
With only diffirent that obviously they were innovator. Even though outside
Delphi absolutely none talks about Delphi.
Delphi is surprisingly strong. Actually Delphis popularity is an undeniable
proof how massively successful Smalltalk has been in its
visual paradigm. Its company went to bankruptcy and the language was bought
by a pretty much , even today, unknown company. The impact was that it went
from 4th most popular to 12th most popular.
Delphi even today is a formidable force for the Windows platform battling
Go and freaking Swift who has the support of the most powerful company on
the planet, Apple.There is no doubt in my mind
that if Delphi was not such a massively loved IDE , being closed source
which is a taboo for todays coding standards especially for a programming
language, it would have been long dead.

And lets not begin with scripting language which are basically dead. Python
for example may be the 3rd most popular programming language but scripting
wise has pretty much died.
When it comes to the customisation of super advanced programs , the users
has spoken loud and clear. They want visual coding and NOT text coding.
3 extremely complex fields , 3d graphics , Music and game development are
dominated by Visual Coding languages. In Blender we offer both Python and
Visual coding,
guess what the users pick.

Essentially one type of Visual Coding , node based visual coding.

Also the time where visual coding was just for the users and not for the
pros is long gone too after the massive success of Unreal's Blueprints.
Which basically can do everything C++ can.
Unreal's Blueprints is not even the first example of a visual language that
will give a text language a run for its money. Softimage (3d app) ICE has
been doing high performance coding decades ago.
In music software we even have the insanity of visual language going down
to low level, an I am not talking C++ or C , I mean real low level, old
school Assembly code. Again decades ago.

The users have spoken loud and clear and they have clearly stated they have
no interest into investing the vast amount of wasted time that text coding
requires.

Even to learn how to code is dominated by Scratch. Just think about it, a
language for kids dominates programming education.
If you told that to a coder or even a user 20 years ago, he would have
called you crazy and for a good reason.

Text coding is only getting less and less popular by the year. I have no
doubt at some point will completely disappear as did Assembly.

So the biggest mistake of Smalltalk was not that it supported visual coding

it was that it did not go visual coding all the way.

It will have saved us the trouble of not being able to convince people to
learn coding.
Because people do not want to learn coding,
And frankly I do not blame them.

Visual coding is the only future of coding and Emac and Vim are relics of a
past that has long gone.
A despair attempt at nostalgia.
On Fri, Jan 25, 2019 at 1:09 AM Hernán Morales Durand <
hernan.mora...@gmail.com> wrote:

> El jue., 24 ene. 2019 a las 13:18, Sven Van Caekenberghe ()
> escribió:
>
>>
>>
>> > On 24 Jan 2019, at 17:04, K K Subbu  wrote:
>> >
>> > On 24/01/19 7:23 PM, Sven Van Caekenberghe wrote:
>> >> Everybody is of course totally free to do whatever they want, but
>> >> really, why the hell would you want to do that ?
>> > Because text has many uses other than just feeding into a compiler for
>> translation to machine code? People who come from Unix/Linux world are used
>> to using a rich collection of tools that deal with text in various ways.
>>
>> I am myself a server/linux guy, an emacs user, I know what is all
>> possible and what the unix philosophy is.
>>
>> I also know how to integrate Pharo into that world, and this is super
>> important.
>>
>> >> You lose so much by doing that, I do not even know where to start.
>> >
>> > Live coding (i.e. coding in the presence of instances) is undoubtedly
>> more powerful than edit-compile-run cycle. Text is used to direct IDE to
>> edit live objects. But text has many more uses than just issuing commands.
>> If beginners start using vim just to edit code due to established 

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Dimitris Chloupis]

yeah the System Browser has some shortcuts that you can find if you click
that down arrow in top right corner of the window

About getting Window info, that is tricky, all is available through Morphic
but Morphic is kinda messy. So if you are willing to do the hard work its
definetly doable , you can create your own shortcuts etc.

Finding the leftmost probably you will ask the World morph about all
windows , ask each window whether its opened and if yes where is located
(morph >>position)
I think the focus is in SystemWindow >> isActive , look also at
basicActivate for a better idea what activation means

For groups there is isEmbeded , also Morph >> embededMorphs

No idea about the Playground, it keeps timestamped session of whatever you
do so there is definetly something

Yeah Pharo is not Emacs that's for sure. Mainly because we attract people
who are mouse driven, people who are keyboard driven tend to avoid IDEs.
Its doable , its just not available out of the box.

I can feel your pain though, this has been an issue for me with Pharo, the
power is there, but its not easy to access. However to be fair Emacs has
been around a lot longer and has far larger community of contributors so
its no wonder it can do these things with ease. Emacs also has amazing
documentation. But sadly is no IDE and its shortcuts is pure insanity, but
then I am a mouse person myself. Ironically I was raised on CLIs and I
always hated them with passion :D

On Thu, Jan 24, 2019 at 8:32 PM Jose San Leandro 
wrote:

> I don't want to hijack this thread, but it would be useful for me to have
> a cheatsheet to allow me to do the usual operations I do with the mouse,
> programatically. I've had some difficulties with simple things in the past.
> For example, to delete all Transcript or Playground windows, I use calls
> such as
>
> (World submorphs select: [ :w | ((w model printString beginsWith: 'a
>> GTPlayground') or: [ w model printString beginsWith: 'Transcript' ]) not ])
>> do: [ :w | w delete ].
>>
>
> I'm missing ways to query World submorphs to know exactly my target
> instance. For example:
> - Which is the leftmost window?
> - Which window has the focus?
> - Which windows have "grouping" enabled?
> - Which Playground instance I used more recently?
>
> And operations such as:
> - Maximize morph.
> - Activate "class side" in Nautilus.
> - Select "accessing" protocol.
> - Select package X.
> - Select "Hierarchy".
> - Choose the next child when "hierarchy" is active.
>
>> - Resize the method panel.
>>
>
> Also, basic things like:
> - Move to the next word.
> - Highlight previous word.
> - Highlight current line.
>
> That would be very helpful for me. I'm not saying it's difficult to do,
> I'm just saying for me it'd be helpful.
> That's basically why I love Emacs, because I can do with the keyboard
> anything that can be done with the mouse, and more.
>
> Thanks!
>
> El jue., 24 ene. 2019 a las 19:05, Dimitris Chloupis (<
> kilon.al...@gmail.com>) escribió:
>
>> Playground is a REPL inside Pharo so I am not sure I understand what you
>> are asking. Everything in Pharo is just Classes and methods so you can do
>> whatever you want. If you are a bit more descriptive maybe I can help you
>> more. There is no such thing as a bad idea, just an idea that has not
>> mature enough :D
>>
>> On Thu, Jan 24, 2019 at 7:53 PM Jose San Leandro <
>> jose.sanlean...@osoco.es> wrote:
>>
>>> I was aware of that. I was imaging a way to use the tools available in
>>> Pharo, but within a REPL session.
>>> Probably a bad idea anyway. I just think the mouse is useful when
>>> exploring, but it's ridiculously inefficient once you know exactly what you
>>> want to do.
>>> In my 4k monitor I often feel like if I was saying "no, I want to resize
>>> the window, not moving it, not changing the focus, thanks". I have to waste
>>> time being accurate enough with the mouse, because it's the expected way to
>>> communicate with live objects. Mouse, then keyboard. Not good.
>>>
>>> El jue., 24 ene. 2019 a las 18:36, Dimitris Chloupis (<
>>> kilon.al...@gmail.com>) escribió:
>>>
>>>> "I am sure there will always be skeptics. But my own experience was
>>>> different. For me, the most weird thing about Squeak (and now Pharo)
>>>> IDE
>>>> is its insistence in showing only one method at a time. A method is too
>>>> small a chunk of code. It is easy to miss the forest for the trees. In
>>>> Dimitris video, you see lots more code in one glance in vim session. So
>>>

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Dimitris Chloupis]

Playground is a REPL inside Pharo so I am not sure I understand what you
are asking. Everything in Pharo is just Classes and methods so you can do
whatever you want. If you are a bit more descriptive maybe I can help you
more. There is no such thing as a bad idea, just an idea that has not
mature enough :D

On Thu, Jan 24, 2019 at 7:53 PM Jose San Leandro 
wrote:

> I was aware of that. I was imaging a way to use the tools available in
> Pharo, but within a REPL session.
> Probably a bad idea anyway. I just think the mouse is useful when
> exploring, but it's ridiculously inefficient once you know exactly what you
> want to do.
> In my 4k monitor I often feel like if I was saying "no, I want to resize
> the window, not moving it, not changing the focus, thanks". I have to waste
> time being accurate enough with the mouse, because it's the expected way to
> communicate with live objects. Mouse, then keyboard. Not good.
>
> El jue., 24 ene. 2019 a las 18:36, Dimitris Chloupis (<
> kilon.al...@gmail.com>) escribió:
>
>> "I am sure there will always be skeptics. But my own experience was
>> different. For me, the most weird thing about Squeak (and now Pharo) IDE
>> is its insistence in showing only one method at a time. A method is too
>> small a chunk of code. It is easy to miss the forest for the trees. In
>> Dimitris video, you see lots more code in one glance in vim session. So
>> there are pragmatic reasons why some coders fallback to using fileOuts
>> for browsing classes."
>>
>> I could not agree more , I find the column GUI weird and a waste of
>> space. This is why I have ended up relying a lot on GTSpotter (finder)
>> which help me browse classes a lot faster than the class browser. Kinda
>> ironic.
>>
>> I am using Pharo since 2011. I am still dont like Class Browser :D
>>
>> "In summary, if someone misses Emacs or Vim when working with Pharo, it
>> could be due to:
>> - being stuck in the file-based way to think of coding.
>> "
>> Its a common misconception that Pharo does not heavily rely on text
>> files, it actually does. Not only the source file makes it possible to view
>> the code even the oldest method of version control tha Pharo being a fork,
>> inherited from Squeak, the known mcz files they may look small binary files
>> like the Pharo image but they are merely zip files with source code text
>> files with the st extension.
>>
>> The image is merely the bytecode, the VMs machine code sort of, the
>> actually source works the same way as other languages. Like other languages
>> you dont need the source code to execute , only the bytecode. What makes
>> the image special is that its one file and its a memory dump which makes it
>> easy to store both live code and live state. Which is very helpful,
>> technically its mandatory for true live coding, but still Pharo has to rely
>> on source code files to make our lives easy. From there on is just a
>> question whether you break the source code files in several small ones, or
>> keep one large.
>>
>> "Besides that, is there an easy way to run an image in text-only mode,
>> with a REPL or a playground or something like that?"
>>
>> Yeap its possible and has been around for a very long time. Pharo also
>> makes it dead easy to expose any method as command line argument, so its
>> possible to code completely from the command line although definitely not
>> recommended.
>>
>> Deep Into Pharo book explains how.
>>
>> On Thu, Jan 24, 2019 at 7:17 PM K K Subbu  wrote:
>>
>>> On 24/01/19 9:47 PM, Sven Van Caekenberghe wrote:
>>> >
>>> >
>>> >> On 24 Jan 2019, at 17:04, K K Subbu  wrote:
>>> >>
>>> >> On 24/01/19 7:23 PM, Sven Van Caekenberghe wrote:
>>> >>> Everybody is of course totally free to do whatever they want,
>>> >>> but really, why the hell would you want to do that ?
>>> >> Because text has many uses other than just feeding into a compiler
>>> >> for translation to machine code? People who come from Unix/Linux
>>> >> world are used to using a rich collection of tools that deal with
>>> >> text in various ways.
>>> >
>>> > I am myself a server/linux guy, an emacs user, I know what is all
>>> > possible and what the unix philosophy is.
>>>
>>>
>>> No offense intended. Just wanted to point out that text can have
>>> different purposes. Historically, Smalltalk presented itself as a
>>> OS+IDE. Today, that is no longer true. Pha

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Dimitris Chloupis]

"I am sure there will always be skeptics. But my own experience was
different. For me, the most weird thing about Squeak (and now Pharo) IDE
is its insistence in showing only one method at a time. A method is too
small a chunk of code. It is easy to miss the forest for the trees. In
Dimitris video, you see lots more code in one glance in vim session. So
there are pragmatic reasons why some coders fallback to using fileOuts
for browsing classes."

I could not agree more , I find the column GUI weird and a waste of space.
This is why I have ended up relying a lot on GTSpotter (finder) which help
me browse classes a lot faster than the class browser. Kinda ironic.

I am using Pharo since 2011. I am still dont like Class Browser :D

"In summary, if someone misses Emacs or Vim when working with Pharo, it
could be due to:
- being stuck in the file-based way to think of coding.
"
Its a common misconception that Pharo does not heavily rely on text files,
it actually does. Not only the source file makes it possible to view the
code even the oldest method of version control tha Pharo being a fork,
inherited from Squeak, the known mcz files they may look small binary files
like the Pharo image but they are merely zip files with source code text
files with the st extension.

The image is merely the bytecode, the VMs machine code sort of, the
actually source works the same way as other languages. Like other languages
you dont need the source code to execute , only the bytecode. What makes
the image special is that its one file and its a memory dump which makes it
easy to store both live code and live state. Which is very helpful,
technically its mandatory for true live coding, but still Pharo has to rely
on source code files to make our lives easy. From there on is just a
question whether you break the source code files in several small ones, or
keep one large.

"Besides that, is there an easy way to run an image in text-only mode, with
a REPL or a playground or something like that?"

Yeap its possible and has been around for a very long time. Pharo also
makes it dead easy to expose any method as command line argument, so its
possible to code completely from the command line although definitely not
recommended.

Deep Into Pharo book explains how.

On Thu, Jan 24, 2019 at 7:17 PM K K Subbu  wrote:

> On 24/01/19 9:47 PM, Sven Van Caekenberghe wrote:
> >
> >
> >> On 24 Jan 2019, at 17:04, K K Subbu  wrote:
> >>
> >> On 24/01/19 7:23 PM, Sven Van Caekenberghe wrote:
> >>> Everybody is of course totally free to do whatever they want,
> >>> but really, why the hell would you want to do that ?
> >> Because text has many uses other than just feeding into a compiler
> >> for translation to machine code? People who come from Unix/Linux
> >> world are used to using a rich collection of tools that deal with
> >> text in various ways.
> >
> > I am myself a server/linux guy, an emacs user, I know what is all
> > possible and what the unix philosophy is.
>
>
> No offense intended. Just wanted to point out that text can have
> different purposes. Historically, Smalltalk presented itself as a
> OS+IDE. Today, that is no longer true. Pharo is just a multi-platform IDE.
>
> > I also know how to integrate Pharo into that world, and this is super
> > important.
> Thanks. This is what I intended to bring out.
>
> >>> You lose so much by doing that, I do not even know where to
> >>> start.
> >>
> >> Live coding (i.e. coding in the presence of instances) is
> >> undoubtedly more powerful than edit-compile-run cycle. Text is used
> >> to direct IDE to edit live objects. But text has many more uses
> >> than just issuing commands.  If beginners start using vim just to
> >> edit code due to established habits, they will soon realize the
> >> ease of live coding and remain in IDE. This is a self-correcting
> >> error.
> >
> > Well, I don't think so.
> > The users that you are going to attract in this way (the ones that
> > don't want to leave their own IDE/editor), will look at textual Pharo
> > and find it very strange and ill suited to textual editing (and they
> > are absolutely right), they will not discover the power, will not
> > learn (from this experience alone) what object
> > design/programming/power is, and will ask for more (e.g. give me ,
> > style compiler errors, better/easier structure of the file, fixed the
> > !! escape issue, etc, ...).
>
> I am sure there will always be skeptics. But my own experience was
> different. For me, the most weird thing about Squeak (and now Pharo) IDE
> is its insistence in showing only one method at a time. A method is too
> small a chunk of code. It is easy to miss the forest for the trees. In
> Dimitris video, you see lots more code in one glance in vim session. So
> there are pragmatic reasons why some coders fallback to using fileOuts
> for browsing classes.
>
> Regards .. Subbu
>
>

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 7.0 released!

[Dimitris Chloupis]

64 bit is finally here, amazing work guys, I was thinking making a torrent
client of sorts with Pharo using libtorrent library
https://www.libtorrent.org/

To anyone who has not tried the FFI , you should even if you dont care
about C its amazingly well designed , so kudos to Esteban, Igor and whoever
else contributed in this beauty

That's my No1

My No2 is GTSpotter, any news on that front ? Does Pharo 7 offer something
new ?

On Thu, Jan 24, 2019 at 3:04 AM Pierce Ng  wrote:

> On Wed, Jan 23, 2019 at 06:43:50PM -0500, Offray Vladimir Luna Cárdenas
> wrote:
> > I joined HN just to be able to comment on this thread[1]. Yes, it seems
> > [1] https://news.ycombinator.com/item?id=18984409
>
> Kudos for a measured response.
>
>
>

Re: [Pharo-users] Website is down

[Dimitris Chloupis]

Personally I like the idea of turning this into a static web site, static
websites can use bootstrap so they can play well with mobile devices too
and then its easy to host on Github or Gitlab or whatever and avoid such
pains. It will also make it much easier to manage. But hey I am nowhere
near to being a web dev so what do I know :D

On Thu, Jan 24, 2019 at 3:23 AM john pfersich  wrote:

> Maybe ask more people to join the Pharo Association to get funds to move
> the file server to a infrastructure that can handle a higher volume of
> traffic. I know that I’d be willing to increase my Bountysource
> contribution to help cover the cost. I don’t use Pharo professionally, but
> I try to push Smalltalk, and Pharo specifically as a solution in my work
> assignments.
>
> Sent from my iPhone
> https://boincstats.com/signature/-1/user/51616339056/sig.png
> See https://objectnets.net and https://objectnets.org
>
> > On Jan 23, 2019, at 13:57, Todd Blanchard  wrote:
> >
> > Is it a static website or does it have code behind it?
> >
> > Could we use S3 at AWS?
> >
> >> On Jan 22, 2019, at 9:37 AM, Esteban Maringolo 
> wrote:
> >>
> >> El mar., 22 ene. 2019 a las 14:03, Esteban Lorenzano
> >> () escribió:
> >>>
> >>> There is a problem with INRIA servers :(
> >>> They does not seems to support high traffic
> >>>
> >>
> >> They don't support high traffic nor high volume either. The download
> >> speed was awful then, and it's even worst now.
> >> But hey, those who pass all these obstacles to get to know and try
> >> Pharo are more likely to continue using it. :)
> >>
> >>
> >>> (supposing public from reddit and yc is high traffic?)
> >>
> >> Well... with at least a 100:1 ratio of visits:upvotes the hits must be
> >> at least two order of magnitude higher than on a regular day.
> >> Which makes me wonder... do we have any stats of that?
> >>
> >> These problems are "good" problems, and are the easiest to solve.
> >>
> >>
> >> Esteban A. Maringolo
> >>
> >
> >
>
>

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Dimitris Chloupis]

"Honestly, Pharo without the environment (and the “live objects” approach)
is just another dynamic language without much interest.
Thinking the IDE is just autocompletion is a poor idea of what a live
environment can do for you."

And I repeat once more, I NEVER said use external editor instead of Pharo,
I said use external editor with Pharo. No idea how to make this any more
clear. With my approach you sacrifice nothing from Pharo.

"These are all valid points (and I started by saying that everybody is free
to do whatever they want), but wouldn't you agree that the best experience
is"

Nothing absolutely nothing in my book comes remotely close to how polished
Delphi and amazingly powerful IDE with great GUI design,
No I dont agree emacs is an IDE at all, even setting up its tools is a huge
pain. I tried to set it up for Python coding and it tooks me ages to reach
absolutely zero. Vim is nowhere near to being an IDE. Lispworks I have no
idea never used it , same story with mathematica. I have used PyCharm which
is I think is the equivelant of IntelliJ, well designed IDE but too weak
for my taste. XCode only supports ObjC and Swift and as an IDE , even
though an Apple product it lets a lot to be desired in GUI design and also
not impressive.

So for me its first Delphi or its open source variant Free Pascal/Lazarus
and then is Pharo. Suprisingly Visual Studio is a nice IDE (just nice) but
not VSCode which I currently use which is 100% code editor.

To be sincere I have given up on the idea of IDEs mainly because even with
Pharo it was a huge pain to customise them, usual coding problem of lack of
documentation, no code comments etc. Nowdays I design my own dev tools from
scratch, they are not pretty but get the job done partially and at least I
know the code well enough to easily improve it.

My livecoding lib has become quite usable lately and now I am slowly
venturing into the territory of memory managment and data visualisation.

The IDE for me is a very personal experience, of course that does not mean
that Pharo and Delphi are not still my idols. Love them both. They are
amazing restaurants, with the best chefs in the world but in the end
nothing is like home made food.

I dont agree that Smalltalk without an IDE is a Smalltalk, thus I do not
consider GNU Smalltalk a Smalltalk at all.

"Giving people a subpar entry into our world will probably not convince
them that there is something cool to be seen there."

I think my video tutorials have given more than enough good reason to use
Pharo and even more to love Pharo. I find it hard to believe that one video
tutorial going to change that. I never hidden my love for Pharo. Also for
me live coding has become mandatory anyway which why I went to such great
extends to implement it in Python and C. Mind you nowhere near the Pharo's
elegance but it works.

"Nice clip - short and sweet. You may want to point people to about chunk
file format in the description to alert people who may break chunk
syntax by accident and get confused when fileIn breaks (been there, done
that :-(). Also a caveat not to edit *.changes or *.sources though they
look very similar to *.st files."

I have explicitly said to edit only st files, no idea how to make myself
any more clear. Although sometime making mistakes is a great excuse to
learn something. Because I never intended this to be a replacement for
Pharo , I thought unnecessary to focus on the syntax of the st file format.

I think I should add a warning to the video "WARNING THIS IS NO
REPLACEMENT FOR PHARO BUT AN EXTENSION".

"The users that you are going to attract in this way (the ones that don't
want to leave their own IDE/editor), will look at textual Pharo and find it
very strange and ill suited to textual editing (and they are absolutely
right), they will not discover the power, will not learn (from this
experience alone) what object design/programming/power is, and will ask for
more (e.g. give me C style compiler errors, better/easier structure of the
file, fixed the !! escape issue, etc, ...)."

I think you are a bit too optimistic. People if they dont like something
they just give up and move on. When was the last time you saw a post here
by a person saying "I like to use Pharo but I will not because it does not
have X". Rarely if not never, because these type of people you describe are
gone in 50 seconds.

To be sincere if my video makes them leave, awesome, we dont need people
who dont use Pharo complaining about Pharo. And plus I would love someone
to even mention C, I have like an army of complains about this language and
I have to use it everyday. Well at least is not as bad as C++. Thank God
!

By they way we had this discussion before in the community. When I first
mentioned Git and Github (2011) back when using Git with Pharo and
especially an external website to upload code was unthinkable , if not
heretic,  I can remember how many told me that this would be an excuse for
people not to learn Pharo. 

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Dimitris Chloupis]

"Thank you! I'm one of those"
"wow.. thank you :D"

"Everybody is of course totally free to do whatever they want, but really,
why the hell would you want to do that ?"

I can think a few million reasons. Vim and Emacs for example with tons of
internal and external tools , handling code, documentation, unit testing,
integration with other languages. The list is very long.

I think for me that I am not a shortcuts person which is usually the reason
why people want to do this, I really like the idea of Workspaces/Projects
in Visual Code. They are great for managing big project especially if you
mix several languages together. Another good reason is dealing with
markdown which is a popular way of documentation and quite convenient. Git
support is extremely well done Visual Code for example tells me each line
what commit is related to and direct acccess with good visualisation of
remote git repositories.

"A big part of what makes Pharo (or any Smalltalk) special is the IDE
written in itself."

There is no doubt that IDE wise Pharo is best to handle refactoring pharo
code, debug etc. But my approach does not lock you down on a single editor.
As I demonstrated in the video you can move easily between Pharo and VS
code and thats the whole point, you can take advantage of the best of both
worlds.

"There is for example https://github.com/dmatveev/shampoo-emacs which
already makes a bit more sense (but even then)."

I am fully aware of emacs shampoo I used to recommend it but not any more
for the simple fact it has not been updated for 6 years. Shampoo also is
not just about code editing its also a port of the smalltalk IDE to emacs.

I am talking strictly code editing here and various other tools that can be
found in those editors that simply do not exist in Pharo, I am not talking
about IDEs. Why not have your cake and eat it too if you can ?

The whole point of my video was how to use external editor with Pharo and
not to replace Pharo completely which I think what you talking about here.
Coding editing in Pharo has still a long way to go, we do not even have an
easy way to setup keyboard shortcuts which is essential not for me but at
least for others.

We all want to live completely inside the image but in reality those
features take time to implement and is a lot of work for our small
community.

By the way neither Emacs, Vim or Visual Studio Code are IDEs.Just powerful
editors with some IDE features and usually most of the features come in
form of extensions that you have install and configure properly.

In any case I will repeat once again the point of the video is how to taker
advantage of nice features in code editors without having to abandon Pharo.
If this convince people to stick with Pharo I think its a win win
situation. Wouldnt you agree ?

[Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Dimitris Chloupis]

Often we have users of emacs and vim that request a way to use their
favorite shortcuts or features. Some even ask "Would not be nice if I could
use my favorite code editor with Pharo ?"

Actually not only you can do it, its also very easy. So the following video
tutorial explains in the first 3 minutes how to do this and then spends
another 10 min talking about how this could be automated to be completely
automatic and instantaneous.

https://youtu.be/3YfRhDafIxs

[Pharo-users] [ANN] News channel for our Discord Server

[Dimitris Chloupis]

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
this link

https://discord.gg/QewZMZa

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 :)

[Pharo-users] New invite link for Discord

[Dimitris Chloupis]

If you want to join our Discord server click the following link
https://discord.gg/QewZMZa

Re: [Pharo-users] Discord Server invite is now private because of spammer

[Dimitris Chloupis via Pharo-users]

--- Begin Message ---
After discussing it with Stef and Esteban and of course Ben . we reached
the conclusion to have only a few days keeping the invite link private.
After that it will become public again to make it easy for people to join
without any hassle.

If the problem reappears we can discuss whether further action is needed,
in the meantime I will try to ban members generated by the bot. I wont be
deleting it without consulting you first. Admins please refrain from
creating additional invite links, one should be enough and will make
everyone life a lot easier. The new link has no expiration date.

Making the invite link public means that the links to the link , like the
one on the website , will have to be updated to the new one. I do not have
access to those places so people that do will have to update it.

I will make the link public in this thread in a few days. in case the
people that are responsible for sharing the link are not admins in Discord
and they cannot access it.

Again I apologize for the inconvenience but it was a necessary action to
minimize the problem. I am at your disposal for any further clarification
and assistance.

On Sat, Jan 5, 2019 at 10:00 PM Dimitris Chloupis via Pharo-users <
pharo-users@lists.pharo.org> wrote:

> I leave the handling of the invite link up to the admins. I made several
> of you admins as experienced members of this community so that you can
> handle situations like this. As always my policy has been to make the first
> step and let others do the rest.
>
> The incident is not one, I had to ban 3 members , obviously dummy accounts
> for the spammer, to have to delete the invites. When it was first
> recommended I refused to do it but as they say, third is the charm.
>
> If you use several invites there will be no way to know which invite was
> used by the spammer.
>
> I do not think disabling the embeding of links is a good idea, cause we
> heavily rely on them , especially for helping newcomers. It will also make
> little diffirence to the spamming because the bots wont care and continue
> spamming. Those members are clearly bots because the same exact message is
> post each time and I doubt that someone goes to this trouble to do this
> manually.
>
> In any case, I leave it up to the community, if you want the old method
> and endure the spamming that's up to you. I do not have the time or desire
> to do heavy moderation anyway, so its unlikely any method will be future
> proof.Any direction you decide to follow, you have my blessing.
>
> In any case spamming is far from Discord exclusive problem and it has
> happened even in this mailing list. So there is no ideal solution.
>
> On Sat, Jan 5, 2019 at 8:58 PM Ben Coman  wrote:
>
>> On Sun, 6 Jan 2019 at 00:00, Dimitris Chloupis via Pharo-users <
>> pharo-users@lists.pharo.org> wrote:
>>
>>> Hello people , as you may or may not be aware we have a spammer that
>>> posts links to sexual content sites. This is of course an unacceptable
>>> situation so I had to delete all existing invite links.
>>>
>>> This means that from now on I will not allow members to create their own
>>> invite links and I will also not allow more than one link to be active at
>>> a  time so I know which link is compromised.
>>>
>>
>> This would be good to manage better.  Its unfortunate that there seems no
>> way to detect which link a spammer joined through.
>>
>>
>>
>>> The invite link will no longer be public but shared privately only by
>>> Admins to people who are already active here and it will be shared only
>>> through personal emails and messages.
>>>
>>
>> I don't see how that arrangement will be workable for newcomers that need
>> help.
>> One of the benefits of instant messaging is that it lowers the barrier of
>> entry for people learning Pharo to receive help.
>>
>>
>>
>>> I have also raised the level of automatic moderation , from now on new
>>> members wont be able to post in our server unless they have a verified
>>> email with Discord. Also all messages are automatically scanned by Discord
>>> from now on for improper behavior.
>>>
>>
>> This is good.  Live and learn.
>>
>>
>>>
>>> I am sorry for this inconvenience but its all part of having a very
>>> active community, it was just a matter of time till we attracted the
>>> attention of spammers.
>>>
>>> This does not affect our almost 1000 existing members on Discord server
>>> so if you already a member you have nothing to worry about. This affects
>>> only new people who like to join.
>>>
>>> If y

Re: [Pharo-users] Discord Server invite is now private because of spammer

[Dimitris Chloupis via Pharo-users]

--- Begin Message ---
I leave the handling of the invite link up to the admins. I made several of
you admins as experienced members of this community so that you can handle
situations like this. As always my policy has been to make the first step
and let others do the rest.

The incident is not one, I had to ban 3 members , obviously dummy accounts
for the spammer, to have to delete the invites. When it was first
recommended I refused to do it but as they say, third is the charm.

If you use several invites there will be no way to know which invite was
used by the spammer.

I do not think disabling the embeding of links is a good idea, cause we
heavily rely on them , especially for helping newcomers. It will also make
little diffirence to the spamming because the bots wont care and continue
spamming. Those members are clearly bots because the same exact message is
post each time and I doubt that someone goes to this trouble to do this
manually.

In any case, I leave it up to the community, if you want the old method and
endure the spamming that's up to you. I do not have the time or desire to
do heavy moderation anyway, so its unlikely any method will be future
proof.Any direction you decide to follow, you have my blessing.

In any case spamming is far from Discord exclusive problem and it has
happened even in this mailing list. So there is no ideal solution.

On Sat, Jan 5, 2019 at 8:58 PM Ben Coman  wrote:

> On Sun, 6 Jan 2019 at 00:00, Dimitris Chloupis via Pharo-users <
> pharo-users@lists.pharo.org> wrote:
>
>> Hello people , as you may or may not be aware we have a spammer that
>> posts links to sexual content sites. This is of course an unacceptable
>> situation so I had to delete all existing invite links.
>>
>> This means that from now on I will not allow members to create their own
>> invite links and I will also not allow more than one link to be active at
>> a  time so I know which link is compromised.
>>
>
> This would be good to manage better.  Its unfortunate that there seems no
> way to detect which link a spammer joined through.
>
>
>
>> The invite link will no longer be public but shared privately only by
>> Admins to people who are already active here and it will be shared only
>> through personal emails and messages.
>>
>
> I don't see how that arrangement will be workable for newcomers that need
> help.
> One of the benefits of instant messaging is that it lowers the barrier of
> entry for people learning Pharo to receive help.
>
>
>
>> I have also raised the level of automatic moderation , from now on new
>> members wont be able to post in our server unless they have a verified
>> email with Discord. Also all messages are automatically scanned by Discord
>> from now on for improper behavior.
>>
>
> This is good.  Live and learn.
>
>
>>
>> I am sorry for this inconvenience but its all part of having a very
>> active community, it was just a matter of time till we attracted the
>> attention of spammers.
>>
>> This does not affect our almost 1000 existing members on Discord server
>> so if you already a member you have nothing to worry about. This affects
>> only new people who like to join.
>>
>> If you are new and you like to join I will send you an invite link ONLY
>> if you are active in this mailing list and after you are ask for one. You
>> can use this thread by providing your Discord ID (you get this when you
>> register with discord) and I will send you a personal message in Discord
>> with an invite link. By active I mean that you have substantial
>> participation in this mailing list which means at least 3 posts.
>>
>
> This policy seems like an overkill for a first incident.   It introduces a
> chicken-and-egg problem in attracting new users.  Someone trying out Pharo
> who is a potential new user and co-developer.  They don't yet care enough
> or know enough about Pharo to substantially participate in the mail list,
> but they a quick chat right now would sort out something souring their view
> of Pharo .  But if they need to wait to make three posts plus then someone
> being available on their timezone to email them an invite, they may just
> drop it.
>
>
>
>
>> If you are a member or admin and post the link publicly , its not a
>> problem, but please be aware that if the link is compromised then I will
>> delete it and create new making new members unable to join with the old
>> one. So use the link wisely.
>>
>
> New invites are required for the web page and Pharo's built-in help page.
> Probably better to have separate invites for each since the former is more
> likely to be scraped by spammers.
>
> As an alternative action to wiping all links, disabling new members from
> embedding links might effectively deter spammer from posting links and
> pictures.
>
> cheers -ben
>
--- End Message ---

[Pharo-users] Discord Server invite is now private because of spammer

[Dimitris Chloupis via Pharo-users]

--- Begin Message ---
Hello people , as you may or may not be aware we have a spammer that posts
links to sexual content sites. This is of course an unacceptable situation
so I had to delete all existing invite links.

This means that from now on I will not allow members to create their own
invite links and I will also not allow more than one link to be active at
a  time so I know which link is compromised. The invite link will no longer
be public but shared privately only by Admins to people who are already
active here and it will be shared only through personal emails and
messages.

I have also raised the level of automatic moderation , from now on new
members wont be able to post in our server unless they have a verified
email with Discord. Also all messages are automatically scanned by Discord
from now on for improper behavior.

I am sorry for this inconvenience but its all part of having a very active
community, it was just a matter of time till we attracted the attention of
spammers.

This does not affect our almost 1000 existing members on Discord server so
if you already a member you have nothing to worry about. This affects only
new people who like to join.

If you are new and you like to join I will send you an invite link ONLY if
you are active in this mailing list and after you are ask for one. You can
use this thread by providing your Discord ID (you get this when you
register with discord) and I will send you a personal message in Discord
with an invite link. By active I mean that you have substantial
participation in this mailing list which means at least 3 posts.

If you are a member or admin and post the link publicly , its not a
problem, but please be aware that if the link is compromised then I will
delete it and create new making new members unable to join with the old
one. So use the link wisely.

You can also contact one of the other admins , if you know who they are and
they know who you are. If you dont then use this thread and be patient.
Once you join there are no restrictions or anything else that will make
your life not easy.

Happy Pharoing ;)
--- End Message ---

Re: [Pharo-users] Installing SmaCC

[Dimitris Chloupis]

nice , good to know that is already a feature in another smalltalk
implementation. I decided finally to go against the idea of new sytax or
the heavy usage of Array symbols. Instead I will be using standard 100%
Pharo syntax. Fortunately Smalltalk syntax is so minimal that allows me to
do this without hitting my head against a wall. I have already a prototype
working for simple variable declarations with static types and slowly but
steadily moving forward to the rest of the C syntax. Looks like the ship
has left the port :D

On Fri, Oct 19, 2018 at 4:09 AM Pierce Ng  wrote:

> On Wed, Oct 17, 2018 at 01:38:36PM +0300, Dimitris Chloupis wrote:
> > About your last part on platforms, I will be providing a way to inline C
> > code so one can you use C macros to detect the platform and generate code
> > accordingly.
>
> Smalltalk/X allows inline C. Not sure about macros though, as I don't
> know whether Smalltalk/X runs the C code through the C preprocessor or
> does its own compilationn magic.
>
> Pierce
>
>

Re: [Pharo-users] RBParser bug ? (Morphic corruption)

[Dimitris Chloupis]

ok good to know its fixed, thanks Peter.

On Wed, Oct 17, 2018 at 10:29 PM Peter Uhnak  wrote:

> Yes, this is fixed in P7
> https://pharo.fogbugz.com/f/cases/20212#BugEvent.193460
>
> solution is to close your image and open again, or go to process browser
> and kill the new UI loop that started.
>
> As a workaround you can do parseExpression:onError: (or whatever the name
> is)... or I've made a small wrapper which doesn't suffer from thsi
> https://github.com/peteruhnak/pharo-changes-builder
>
> Peter
>
> On Wed, Oct 17, 2018 at 5:00 PM Dimitris Chloupis 
> wrote:
>
>> If I do something normal in the Playground like
>> RBParser parseExpression: 'bac' and inspect it , it works fine
>>
>> If I do something like
>> RBParser parseExpression: 'bac->'. Then it displays an error and things
>> really get weird
>>
>> I get redraw problems with Morphic(if I start moving windows around),
>> with windows leaving trailing images behind and Pharo slowing down.
>>
>> Can anyone reproduce my problem ?
>>
>> I can reproduce this behavior in 6.1 32 bit and 64 bit and with other
>> incorrect syntax strings.
>>
>

[Pharo-users] RBParser bug ? (Morphic corruption)

[Dimitris Chloupis]

If I do something normal in the Playground like
RBParser parseExpression: 'bac' and inspect it , it works fine

If I do something like
RBParser parseExpression: 'bac->'. Then it displays an error and things
really get weird

I get redraw problems with Morphic(if I start moving windows around), with
windows leaving trailing images behind and Pharo slowing down.

Can anyone reproduce my problem ?

I can reproduce this behavior in 6.1 32 bit and 64 bit and with other
incorrect syntax strings.

Re: [Pharo-users] Installing SmaCC

[Dimitris Chloupis]

no I wont be introducing new syntax, I rather keep this 100% smalltalk.Also
LowTalk uses GC which is a no go for me.

this is the "syntax" I am considering so its fully compatible with Pharo
--
SomeClass >> helloWorld: aMessage
#(char* aMessage newMessage).
printf := MagnetarImporter function: 'printf'.
printf aMessage.

newMessage := ' ...end of message'.
prinf newMessage.

#(struct result).
#(int num1 num2 num3).
#(struct end).

#(result myresult).
num1 := 1.
num2 := 2.
num3 := num1 + num2.
#(myresult end).

^ #(myresult)

SomeClass >> main
#(include stdio)
self helloWorld: 'Hello World !!!'


this will compile to C source code


#include 
struct result
{
 int num1;
 int num2;
 int num3;
};

result helloworld(char* aMessage)
{
struct result myresult;
printf(aMessage);
char *newMessage = ' ...end of message.';
myresult.num1 = 1;
myresult.num2 = 2;
myresult.num3 = num1+num2;
return myresult
};

void main()
{
helloWorld('Hello World !!!');
}

Of course this is a work in progress / first idea and if I can further
streamline the syntax so much the better and of course the code could
seperated to diffirent classes etc to follow the smalltalk way.




On Wed, Oct 17, 2018 at 3:20 PM Ben Coman  wrote:

> Perhaps a C-syntax front-end for Lowtalk would be interesting?
>
> http://forum.world.st/Re-ANN-Lowtalk-a-new-Smalltalk-dialect-that-could-eventually-replace-Slang-td4966907.html
>
> cheers -ben
>
>
> On Wed, 17 Oct 2018 at 19:37, Dimitris Chloupis 
> wrote:
>
>> there will be no remap of variable names, this is a strict compiler if
>> you can even call it a compiler. Your variable names will stay exactly the
>> same in the C side , a concern here was that Pharo would not allow to have
>> names like "my_personal_function". All the praise to Pharo it actually
>> allows for such naming for methods.
>>
>> So no this is going to be a very stupid compiler, there will be minimum
>> amount of magic involved if not any at all and what you read in Smalltalk
>> will be compiled exactly the same in C.
>>
>> I am now playing with RBParser for handling the parsing of the smalltalk
>> code and I am impressed how flexible and elegant it is. Kudos to the devs
>> behind it.
>>
>> Here is the begining of Magnatar
>>
>> exp := (RBParser parseExpression: 'Morph call_my_function').
>> sel :=  exp selector asString.
>> classname := exp receiver name asString.
>> Transcript open;clear.
>> Transcript show: classname ; show:'.' ; show:sel;show:'()';cr.
>>
>> Damn that was too easy :D
>>
>> On Wed, Oct 17, 2018 at 2:06 PM Thierry Goubier <
>> thierry.goub...@gmail.com> wrote:
>>
>>> Le mer. 17 oct. 2018 à 12:39, Dimitris Chloupis
>>>  a écrit :
>>> >
>>> > About your last part on platforms, I will be providing a way to inline
>>> C code so one can you use C macros to detect the platform and generate code
>>> accordingly. Or this could happen via a pragma too, it should not be an
>>> issue. This also a reason why I previously talked about an "in place"
>>> annotation and why specially named variables was my first choice instead of
>>> pragmas. I am also not a big fan of pragmas syntax which for me at least
>>> deviates from standard smalltalk syntax style. But as I said I am not
>>> against their usage at all.
>>> >
>>> > Generally because this is no an afternoon project obviously, I will be
>>> relying on C code inling at first for special corner cases and then I will
>>> implement them as annotations the more the project moves forward.
>>>
>>> Having a way to do the same as what asm inline is in gcc, but for
>>> hand-written C inside your Smalltalk derivative is cool: remap
>>> variable names, etc, so that your C generator handles all the
>>> interface between the inlined C and the surrounding Smalltalk.
>>>
>>> Same if you also add platform-dependent customisation for generation.
>>>
>>> Thierry
>>>
>>> > On Wed, Oct 17, 2018 at 1:30 PM Dimitris Chloupis <
>>> kilon.al...@gmail.com> wrote:
>>> >>
>>> >> Hello Allistair
>>> >>
>>> >> I have used Slang only once and it was generating code that was
>>> indeed readbale but my aim is for more finer control over the output. Lets
>>> say I want import a specific C header file or I want a string to map to
>>> custom C type I created etc. So yes Slang is by no mean a bad tool at all
>&g

Re: [Pharo-users] Installing SmaCC

[Dimitris Chloupis]

there will be no remap of variable names, this is a strict compiler if you
can even call it a compiler. Your variable names will stay exactly the same
in the C side , a concern here was that Pharo would not allow to have names
like "my_personal_function". All the praise to Pharo it actually allows for
such naming for methods.

So no this is going to be a very stupid compiler, there will be minimum
amount of magic involved if not any at all and what you read in Smalltalk
will be compiled exactly the same in C.

I am now playing with RBParser for handling the parsing of the smalltalk
code and I am impressed how flexible and elegant it is. Kudos to the devs
behind it.

Here is the begining of Magnatar

exp := (RBParser parseExpression: 'Morph call_my_function').
sel :=  exp selector asString.
classname := exp receiver name asString.
Transcript open;clear.
Transcript show: classname ; show:'.' ; show:sel;show:'()';cr.

Damn that was too easy :D

On Wed, Oct 17, 2018 at 2:06 PM Thierry Goubier 
wrote:

> Le mer. 17 oct. 2018 à 12:39, Dimitris Chloupis
>  a écrit :
> >
> > About your last part on platforms, I will be providing a way to inline C
> code so one can you use C macros to detect the platform and generate code
> accordingly. Or this could happen via a pragma too, it should not be an
> issue. This also a reason why I previously talked about an "in place"
> annotation and why specially named variables was my first choice instead of
> pragmas. I am also not a big fan of pragmas syntax which for me at least
> deviates from standard smalltalk syntax style. But as I said I am not
> against their usage at all.
> >
> > Generally because this is no an afternoon project obviously, I will be
> relying on C code inling at first for special corner cases and then I will
> implement them as annotations the more the project moves forward.
>
> Having a way to do the same as what asm inline is in gcc, but for
> hand-written C inside your Smalltalk derivative is cool: remap
> variable names, etc, so that your C generator handles all the
> interface between the inlined C and the surrounding Smalltalk.
>
> Same if you also add platform-dependent customisation for generation.
>
> Thierry
>
> > On Wed, Oct 17, 2018 at 1:30 PM Dimitris Chloupis 
> wrote:
> >>
> >> Hello Allistair
> >>
> >> I have used Slang only once and it was generating code that was indeed
> readbale but my aim is for more finer control over the output. Lets say I
> want import a specific C header file or I want a string to map to custom C
> type I created etc. So yes Slang is by no mean a bad tool at all its just
> is not designed with making source output that is undetectable as
> autogenerated by a human. But I will have to give it a more serious try
> because it may be closer than I initially thought.
> >>
> >> I am not against the usage of pragmas, and indeed are an excellent way
> to annotate stuff , my only concern is when I may want to annotate in place
> for some weird reason , but that may be doable with pragmas as well too.
> >>
> >> Smalltalk code that is 100% smalltalk should be able to execute , you
> mention however the execution of external C functions , problem is that in
> my case that code does not live in DLLs but in an executable so no I am not
> amaing to that level of execution.
> >>
> >> Also I have an easier solution for this too, when I made the CPPBridge,
> which is a Pharo library that allows the usage of C++ libraries from Pharo,
> I used a shared memory bridge to communicate back to Pharo giving the
> ability of both function calls and callbacks. If I really want to capture
> execution I can do it like this which is the exact opposite of what you do,
> instead of the VM capturing the executable it will be the executable
> capturing the VM if that makes any sense. This makes things far easier. As
> a matter of fact not only my CPPBridge does this it also allows to extend
> the pharo image file because it uses memory mapped files for the shared
> memory which like pharo image files are memory dumps. So there is a lot
> potential in that department.
> >>
> >> However my main goal is to use Smalltalk code execution to make sure
> the prototype works on a basic level, there will be a C cide in this
> project obviously which will act like a runtime that will provide live
> coding features. This is also a library I made in C that does this through
> the usage of DLLs that rebuilds and reloads dynamically.
> >>
> >> So I dont really need the VM to execute my code to check that is
> working cause the C compiler and the live coding runtime can handle this. I
> could even hook in the Pharo debugger, I have done this with

Re: [Pharo-users] compiling libraries for Pharo on macOS

[Dimitris Chloupis]

yes exactly There is for Unix (which includes macos and linux)

UnixDynamicLoader >>loadLibrary: filename flag: flag
^ self ffiCall: #(void *dlopen(const char *filename, int flag))

while for windows is
WindowsDynamicLoader>>loadLibrary: lpFileName
^ self ffiCall: #(void *LoadLibrary(String lpFileName))

So UFFI apparently does not seem to deal with path checking at , instead it
lets the DLL loading C functions to do their job. How they do this is
completely dependant on the platform, or you can use my approach I linked
earlier by including your library inside the Pharo folder relative to the
folder of the VM.

But if you want to do this the standard then yes you will have to do this
the standard way ;)

So look at how C does this and you will have your answer. This is a C
question rather a Pharo questions, unless I am missing something here.

On Wed, Oct 17, 2018 at 1:33 PM Michel Onoff  wrote:

> Afaik, dlopen(3), which I presume UFFI uses internally to load (shared)
> libraries on demand (I cannot imagine anything else), looks in
> LD_LIBRARY_PATH (DYLD_LIBRARY_PATH on macOS), not in PATH.
>
>
>
> So let's focus on one of my question again, reworded here:
>
> What is the strategy that UFFI internally uses in its own implementation
> to search for a library? What if that library depends on other libraries
> in turn? Where would these ones be searched for?
>
>
>
>
>
>
>
>
> On 2018-10-17 12:05, Dimitris Chloupis wrote:
> > yeah I apologise for the wrong example , LibC utilises the
> > enviroment/system variables.
> >
> > Generally speaking all OSes have a PATH variable that defines the places
> > where common libraries and tools are to be found. If you are on windows
> > you can type in the command prompt , "PATH", in Linux and MacOS is
> > "$PATH" . You can add your path in Windows using the system variables
> > dialog window, in MacOS and Linux it usually happens via .bash-config
> > file that setups the path but I am not so sure.
> >
> > The easiest way is to do something like macModuleName does in the
> > LGitLibrary class the code is
> >
> > macModuleName
> >  | pluginDir |
> >  pluginDir := Smalltalk vm binary parent / 'Plugins'.
> >  #('libgit2.dylib' 'libgit2.0.dylib')
> >  detect: [ :each | (pluginDir / each) exists ]
> >  ifFound: [ :libName | ^ libName ].
> >
> >  self error: 'Module not found.'
> >
> > Hope that helps
> >
> > On Wed, Oct 17, 2018 at 12:54 PM Michel Onoff  > <mailto:michel.on...@web.de>> wrote:
> >
> > Hi Dimitris,
> >
> > thanks for the long explanation.
> >
> > As you can see from my example, I build the library with the
> >   -undefined dynamic_lookup
> > flag to clang, so this should be compatible with your (3) option if I
> > understand you correctly. Compiling/linking this way should allow the
> > use of dlopen(3) from UFFI during the execution of Pharo code,
> exactly
> > as I try to simulate with my small test programs.
> >
> > Pharo complains about not being able to load the module (the
> library),
> > even if it appears in the Pharo main folder. It does not report
> whether
> > it cannot find it or if it cannot bind it using dlopen(3).
> >
> > Moreover, it is unclear to me how Pharo interacts with
> > DYLD_LIBRARY_PATH
> > (on macOS) or LD_LIBRARY_PATH (on Linux) environment variables if
> they
> > are set.
> >
> > In other words, Where does it search for libraries?
> >
> >
> >
> > Anyway, I'll try your script on cmake.
> >
> >
> > Regards
> > MO
> >
> >
> >
> >
> > for use with dlopen()
> >
> > On 2018-10-17 11:32, Dimitris Chloupis wrote:
> >  > I advice first of all the use of CMake , you can thank me later.
> >  >
> >  > CMake if you are not aware is the standard build system for C/C++
> > , it
> >  > makes it super easy to build and compile projects so you dont
> > have to do
> >  > what you are doing, call the compiler and pass the inifite amount
> of
> >  > compiler flags that it needs.
> >  >
> >  > To understand how to build a library you have to understand first
> > what a
> >  > library is.
> >  >
> >  > Libraries used by Pharo are known as either Shared Libraries on
> > Macos
> >  > (dylib) and Linux (so) but Dynamically Linked Libraries on W

Re: [Pharo-users] Installing SmaCC

[Dimitris Chloupis]

About your last part on platforms, I will be providing a way to inline C
code so one can you use C macros to detect the platform and generate code
accordingly. Or this could happen via a pragma too, it should not be an
issue. This also a reason why I previously talked about an "in place"
annotation and why specially named variables was my first choice instead of
pragmas. I am also not a big fan of pragmas syntax which for me at least
deviates from standard smalltalk syntax style. But as I said I am not
against their usage at all.

Generally because this is no an afternoon project obviously, I will be
relying on C code inling at first for special corner cases and then I will
implement them as annotations the more the project moves forward.

On Wed, Oct 17, 2018 at 1:30 PM Dimitris Chloupis 
wrote:

> Hello Allistair
>
> I have used Slang only once and it was generating code that was indeed
> readbale but my aim is for more finer control over the output. Lets say I
> want import a specific C header file or I want a string to map to custom C
> type I created etc. So yes Slang is by no mean a bad tool at all its just
> is not designed with making source output that is undetectable as
> autogenerated by a human. But I will have to give it a more serious try
> because it may be closer than I initially thought.
>
> I am not against the usage of pragmas, and indeed are an excellent way to
> annotate stuff , my only concern is when I may want to annotate in place
> for some weird reason , but that may be doable with pragmas as well too.
>
> Smalltalk code that is 100% smalltalk should be able to execute , you
> mention however the execution of external C functions , problem is that in
> my case that code does not live in DLLs but in an executable so no I am not
> amaing to that level of execution.
>
> Also I have an easier solution for this too, when I made the CPPBridge,
> which is a Pharo library that allows the usage of C++ libraries from Pharo,
> I used a shared memory bridge to communicate back to Pharo giving the
> ability of both function calls and callbacks. If I really want to capture
> execution I can do it like this which is the exact opposite of what you do,
> instead of the VM capturing the executable it will be the executable
> capturing the VM if that makes any sense. This makes things far easier. As
> a matter of fact not only my CPPBridge does this it also allows to extend
> the pharo image file because it uses memory mapped files for the shared
> memory which like pharo image files are memory dumps. So there is a lot
> potential in that department.
>
> However my main goal is to use Smalltalk code execution to make sure the
> prototype works on a basic level, there will be a C cide in this project
> obviously which will act like a runtime that will provide live coding
> features. This is also a library I made in C that does this through the
> usage of DLLs that rebuilds and reloads dynamically.
>
> So I dont really need the VM to execute my code to check that is working
> cause the C compiler and the live coding runtime can handle this. I could
> even hook in the Pharo debugger, I have done this with my Atlas library
> that allows to use Python library from Pharo by sending the python error
> back to Pharo debugger where it triggers an error and the debugger pops to
> allow you to do your usual live coding magic and basically resends the code
> back to python. Because of my C livecoding library I can do this with C
> too. My only concern is how the C/C++ compiler reports errors because
> obviously it known that it kinda sucks on this. But hey I cannot make C
> better :D
>
> Generally speaking the tools I am making are not designed for general
> consuption but designed to solve my own problems. Of course I like to share
> them because there is always the chance for someone to find them useful as
> it has happened with Atlas for example. Plus as happened with Atlas one can
> take my code and adjust it to his or her personal needs.
>
> On Wed, Oct 17, 2018 at 1:04 PM Alistair Grant 
> wrote:
>
>> Hi Dimitris,
>>
>> As someone currently learning to use Slang (i.e. not an expert), I've
>> added my 2c below...
>>
>> On Wed, 17 Oct 2018 at 11:06, Dimitris Chloupis 
>> wrote:
>> >
>> > Thierry you have done it !!! you just gave a very easy solution to my
>> problems.
>> >
>> > Yeap Slang is quite close to what I am thinking, unfortunately Clement
>> told me to stay away from it because the code is ugly and specially used
>> for VM only. If I remember also correctly it does not generate readable C
>> code either. But the idea as a concept is very close to what I imagine.
>>
>> I've found the C code produced to b

Re: [Pharo-users] Installing SmaCC

[Dimitris Chloupis]

Hello Allistair

I have used Slang only once and it was generating code that was indeed
readbale but my aim is for more finer control over the output. Lets say I
want import a specific C header file or I want a string to map to custom C
type I created etc. So yes Slang is by no mean a bad tool at all its just
is not designed with making source output that is undetectable as
autogenerated by a human. But I will have to give it a more serious try
because it may be closer than I initially thought.

I am not against the usage of pragmas, and indeed are an excellent way to
annotate stuff , my only concern is when I may want to annotate in place
for some weird reason , but that may be doable with pragmas as well too.

Smalltalk code that is 100% smalltalk should be able to execute , you
mention however the execution of external C functions , problem is that in
my case that code does not live in DLLs but in an executable so no I am not
amaing to that level of execution.

Also I have an easier solution for this too, when I made the CPPBridge,
which is a Pharo library that allows the usage of C++ libraries from Pharo,
I used a shared memory bridge to communicate back to Pharo giving the
ability of both function calls and callbacks. If I really want to capture
execution I can do it like this which is the exact opposite of what you do,
instead of the VM capturing the executable it will be the executable
capturing the VM if that makes any sense. This makes things far easier. As
a matter of fact not only my CPPBridge does this it also allows to extend
the pharo image file because it uses memory mapped files for the shared
memory which like pharo image files are memory dumps. So there is a lot
potential in that department.

However my main goal is to use Smalltalk code execution to make sure the
prototype works on a basic level, there will be a C cide in this project
obviously which will act like a runtime that will provide live coding
features. This is also a library I made in C that does this through the
usage of DLLs that rebuilds and reloads dynamically.

So I dont really need the VM to execute my code to check that is working
cause the C compiler and the live coding runtime can handle this. I could
even hook in the Pharo debugger, I have done this with my Atlas library
that allows to use Python library from Pharo by sending the python error
back to Pharo debugger where it triggers an error and the debugger pops to
allow you to do your usual live coding magic and basically resends the code
back to python. Because of my C livecoding library I can do this with C
too. My only concern is how the C/C++ compiler reports errors because
obviously it known that it kinda sucks on this. But hey I cannot make C
better :D

Generally speaking the tools I am making are not designed for general
consuption but designed to solve my own problems. Of course I like to share
them because there is always the chance for someone to find them useful as
it has happened with Atlas for example. Plus as happened with Atlas one can
take my code and adjust it to his or her personal needs.

On Wed, Oct 17, 2018 at 1:04 PM Alistair Grant 
wrote:

> Hi Dimitris,
>
> As someone currently learning to use Slang (i.e. not an expert), I've
> added my 2c below...
>
> On Wed, 17 Oct 2018 at 11:06, Dimitris Chloupis 
> wrote:
> >
> > Thierry you have done it !!! you just gave a very easy solution to my
> problems.
> >
> > Yeap Slang is quite close to what I am thinking, unfortunately Clement
> told me to stay away from it because the code is ugly and specially used
> for VM only. If I remember also correctly it does not generate readable C
> code either. But the idea as a concept is very close to what I imagine.
>
> I've found the C code produced to be quite readable, but that is
> probably influenced by the fact that I have read the slang first.
>
>
> > As a matter of fact you mentioning Slang made  I have an epiphany that I
> dont have to create a new syntax at all, instead I could use specific
> variables or methods to provide type annotation. Thus like Slang I can use
> regular Smalltalk code that avoids changing types but without the need for
> type inference (although I am not excluding this either).
> >
> > So yes I am definetly want to move to the direction that Slang goes so I
> can fully utilise the Pharo IDE and minise code that I have to write.
> >
> > So basically I am thinking write code as you always write in Pharo and
> either
> > a) Have special dictionary variables in each method that provide static
> type annotations for the arguments of the methods, its return type and
> local variables
>
> Slang uses method pragmas to define the variables types.  This seems
> to work quite well.
>
>
> > b) Have special methods that provide such dictionaries seperately.
> >
> > Or probably bo

Re: [Pharo-users] compiling libraries for Pharo on macOS

[Dimitris Chloupis]

yeah I apologise for the wrong example , LibC utilises the
enviroment/system variables.

Generally speaking all OSes have a PATH variable that defines the places
where common libraries and tools are to be found. If you are on windows you
can type in the command prompt , "PATH", in Linux and MacOS is "$PATH" .
You can add your path in Windows using the system variables dialog window,
in MacOS and Linux it usually happens via .bash-config file that setups the
path but I am not so sure.

The easiest way is to do something like macModuleName does in the
LGitLibrary class the code is

macModuleName
| pluginDir |
pluginDir := Smalltalk vm binary parent / 'Plugins'.
#('libgit2.dylib' 'libgit2.0.dylib')
detect: [ :each | (pluginDir / each) exists ]
ifFound: [ :libName | ^ libName ].

self error: 'Module not found.'

Hope that helps

On Wed, Oct 17, 2018 at 12:54 PM Michel Onoff  wrote:

> Hi Dimitris,
>
> thanks for the long explanation.
>
> As you can see from my example, I build the library with the
>  -undefined dynamic_lookup
> flag to clang, so this should be compatible with your (3) option if I
> understand you correctly. Compiling/linking this way should allow the
> use of dlopen(3) from UFFI during the execution of Pharo code, exactly
> as I try to simulate with my small test programs.
>
> Pharo complains about not being able to load the module (the library),
> even if it appears in the Pharo main folder. It does not report whether
> it cannot find it or if it cannot bind it using dlopen(3).
>
> Moreover, it is unclear to me how Pharo interacts with DYLD_LIBRARY_PATH
> (on macOS) or LD_LIBRARY_PATH (on Linux) environment variables if they
> are set.
>
> In other words, Where does it search for libraries?
>
>
>
> Anyway, I'll try your script on cmake.
>
>
> Regards
> MO
>
>
>
>
> for use with dlopen()
>
> On 2018-10-17 11:32, Dimitris Chloupis wrote:
> > I advice first of all the use of CMake , you can thank me later.
> >
> > CMake if you are not aware is the standard build system for C/C++ , it
> > makes it super easy to build and compile projects so you dont have to do
> > what you are doing, call the compiler and pass the inifite amount of
> > compiler flags that it needs.
> >
> > To understand how to build a library you have to understand first what a
> > library is.
> >
> > Libraries used by Pharo are known as either Shared Libraries on Macos
> > (dylib) and Linux (so) but Dynamically Linked Libraries on Windows
> > (DLLs). They are executables designed to be called from another
> > executable (this includes another library as well).
> >
> > Those libraries operate in 3 modes
> > 1) Static linking
> > 2) semi dynamic linking
> > 3) dynamic linking
> >
> > (1) may come as suprise but yes those libraries can be linked to the
> > executable and build inside the exrecutable. But in our case we done
> > want that because it would mean to rebuild the VM.
> > (2) is not what we want either because eventhough it builds the library
> > independently generating the usual exetension files I mentioned above it
> > includes its symbole table in the executable so you wont have to do what
> > UFFI does, wrap or map your code to those library functions. The
> > equivelant for Pharo would mean that we would not need UFFI at all but
> > we do need to rebuld the VM to include ths symbol table. The symbole
> > table basically includes the name of the functions, their signatures
> > (type of arguments) and their corresponing adresses in memory needed to
> > access them.
> >
> > (3) is what UFFI does, in that cause the executable is not affected at
> > all so you dont need to to rebuild the vm. But you do need to know where
> > to find the library , to access its symbol table and make sure the
> > variables your executable uses match the type and signature in the
> > symbol table or else the executable wont able to locate and correctly
> > call these functions. Of course libraries can contain structs and global
> > variables as well but the concept is the same. Now this messy part is
> > handled by the UFFI although barely because it still needs from you to
> > provide the correct signature to the function.
> >
> > I am giving you the long version because you have to make sure you build
> > you library with (3) way and not (2). (1) can be easily avoid but it is
> > easy to mix (2) and (3). From there on its easy , locating the library
> > is provided as a string returned by a method , see how UFFI utilises
> > LibC for example and from there on you just convert the signature

Re: [Pharo-users] compiling libraries for Pharo on macOS

[Dimitris Chloupis]

I advice first of all the use of CMake , you can thank me later.

CMake if you are not aware is the standard build system for C/C++ , it
makes it super easy to build and compile projects so you dont have to do
what you are doing, call the compiler and pass the inifite amount of
compiler flags that it needs.

To understand how to build a library you have to understand first what a
library is.

Libraries used by Pharo are known as either Shared Libraries on Macos
(dylib) and Linux (so) but Dynamically Linked Libraries on Windows (DLLs).
They are executables designed to be called from another executable (this
includes another library as well).

Those libraries operate in 3 modes
1) Static linking
2) semi dynamic linking
3) dynamic linking

(1) may come as suprise but yes those libraries can be linked to the
executable and build inside the exrecutable. But in our case we done want
that because it would mean to rebuild the VM.
(2) is not what we want either because eventhough it builds the library
independently generating the usual exetension files I mentioned above it
includes its symbole table in the executable so you wont have to do what
UFFI does, wrap or map your code to those library functions. The equivelant
for Pharo would mean that we would not need UFFI at all but we do need to
rebuld the VM to include ths symbol table. The symbole table basically
includes the name of the functions, their signatures (type of arguments)
and their corresponing adresses in memory needed to access them.

(3) is what UFFI does, in that cause the executable is not affected at all
so you dont need to to rebuild the vm. But you do need to know where to
find the library , to access its symbol table and make sure the variables
your executable uses match the type and signature in the symbol table or
else the executable wont able to locate and correctly call these functions.
Of course libraries can contain structs and global variables as well but
the concept is the same. Now this messy part is handled by the UFFI
although barely because it still needs from you to provide the correct
signature to the function.

I am giving you the long version because you have to make sure you build
you library with (3) way and not (2). (1) can be easily avoid but it is
easy to mix (2) and (3). From there on its easy , locating the library is
provided as a string returned by a method , see how UFFI utilises LibC for
example and from there on you just convert the signatures to symbol arrays
as described by the UFFI tutorials.

For cmake you only need to use -> add_library(libraryname MODULE ${SRC} ).
You can find a CmakeList.txt file that I use here
https://gist.github.com/kilon/ff4b973bdeb3b0c0253ac373a4b2506a

If you are wondering why its so big, its because the project I link against
is huge and because I move the DLL to its build folder instead of building
it in the same folder as my source code. It CMake's why of keeping things
seperate and organised. Observe also that I use dll exension for Windows
and MacOS, The extensions plays no role so I decided to go for the same
extension to save time although usually its preferable go for the standard
extensions.

Beware that if your library uses any external code even parts of the C
standard library those will have to be included , usually you need only the
header files, which is what SET INC is doing in my example, while SET SRC
includes only the library files. The inclusion of headers is super
important because they are used to build the symbol table which is the most
important part of the library. Without a correctly build symbol table the
library is useless even when used from C/C++.

On Wed, Oct 17, 2018 at 11:09 AM Michel Onoff  wrote:

> Hello,
>
> I've made some attempts to use the Pharo FFI. I've gone through the
> documentation [1] and tried some examples.
>
> While the documentation is quite clear about using external libraries
> from Pharo, it lacks details on how to build own libraries to be used
> from Pharo.
>
> Specifically, I'm trying to build on all supported platforms, namely
> macOS, Windows and Linux. Currently I've got Linux and Windows under
> control, but I cannot find a systematic way to build on macOS.
>
> Here's an example for a library that I can use from a small test program
> but not from Pharo. Unfortunately, the diagnostic on Pharo is not
> detailed: it simply reports that it cannot load the module.
>
>
> clang -I  -O3 -c 
> ...
> clang -dynamiclib  -o lib.dylib -undefined
> dynamic_lookup
>
> cp lib.dylib 
>
>
> Is there good documentation about how to correctly build libraries so
> that they can be used from Pharo?
>
> Alternatively, are there details on how Pharo FFI searches for libraries
> and links them in the Pharo process?
>
>
> Regards
> MO
>
> 
>
> [1] https://files.pharo.org/books-pdfs/booklet-uFFI/UFFIDRAFT.pdf
>
>
>

Re: [Pharo-users] Installing SmaCC

[Dimitris Chloupis]

Thierry you have done it !!! you just gave a very easy solution to my
problems.

Yeap Slang is quite close to what I am thinking, unfortunately Clement told
me to stay away from it because the code is ugly and specially used for VM
only. If I remember also correctly it does not generate readable C code
either. But the idea as a concept is very close to what I imagine.

As a matter of fact you mentioning Slang made  I have an epiphany that I
dont have to create a new syntax at all, instead I could use specific
variables or methods to provide type annotation. Thus like Slang I can use
regular Smalltalk code that avoids changing types but without the need for
type inference (although I am not excluding this either).

So yes I am definetly want to move to the direction that Slang goes so I
can fully utilise the Pharo IDE and minise code that I have to write.

So basically I am thinking write code as you always write in Pharo and
either
a) Have special dictionary variables in each method that provide static
type annotations for the arguments of the methods, its return type and
local variables
b) Have special methods that provide such dictionaries seperately.

Or probably both. This way I can write 100% Smalltalk code and use a very
small compiler to read those dictionary variables for the type of the
variables and functions/structs (essentially a class will be output for a C
struct with pointers to functions for methods and variables for instance
variables). Why invent a whole new language when everything I need already
Pharo provides ?
I could also use special variable dictionaries for all sort of things like
generation of header files, generation of CMake files for automatic
building.

Also I like to use the way UFFI is doing C function signatures by using
symbol arrays.

So thank you all for inspiration it looks like all I need is Pharo AST
methods (which I can from the AST packages) and SmaCC.
So yeap looks like Magnatar will be a new Slang afterall, I will keep you
posted.

Also this also opens the possibility of autowrapping the generated c code
back to Pharo through UFFI, so one can use C code as if its Pharo code. I
can leverage the TalkFFI project that does this already. Seems all the
pieces have fallen in their place.

Keep the suggestions and advice coming, you guys are inspirational :D

On Wed, Oct 17, 2018 at 11:07 AM Thierry Goubier 
wrote:

> Le mer. 17 oct. 2018 à 08:44, Dimitris Chloupis
>  a écrit :
> >
> > Those are interesting languages and probably better ideas than what I am
> thinking. However they are not what I am talking about.
> >
> > The language I am making is called "Magnatar"
> >
> > Magnatar is not Smalltalk, but it is a Smalltalk trojan horse.
> >
> > My main goals are
> >
> > 1) Create 100% readable C code, code that it looks like it was written
> by a person and not automatically generated , leaving no room for suspicion
> > 2) Keep as close to Smalltalk as I can
> > 3) Map to C syntax , one to one
> > 4) Implement a loose variant of OOP
> > 5) Powerful macro system for source manipulation without the need for
> header files
> > 6) CMake integration (automate building which a headache in C/C++)
> >
> > Essentially I am trying to make a language that can allow a smalltalker
> to write C in Smalltalk and none noticing that he did. Hence why I talked
> about a trojan horse. I got the live coding part covered already but I
> would also like to use Pharo as the IDE of the language if I can. Also
> because of (3) Magnatar will be purely statically typed not because I have
> any love for static types but because it makes (3) far easier to
> accomplish. So Magnatar wont be a Smalltalk implementation neither a
> replacement for it.
>
> I believe you're trying to rewrite SLANG...
>
> Maybe you can reuse part of it.
>
> Making a better SLANG would certainly help, in more areas than one!
>
> Thierry
> > This means also that Magnatar will be a way to extend Pharo on low
> level. Writting  readable C using Smalltalky syntax for extensions instead
> of just writting in C and then using Pharo's UFFI. Of course this will
> benefit those that want to squeeze much more performance out of Pharo.
>
> > Magnatar also is not another language trying to take over the world but
> a language I will use to write C code for a project I am working on which
> is 3d graphics and I need the full performance. So in the end it will be a
> personal language.
> >
> > Unfortunately this means no dynamic types at all, no GC , no VM, no
> bytecodes, not intepretation of any sort, no image format. The only thing I
> am keeping will be live coding. Also OOP will be basically super simple,
> only c structs and c functions with a small API to allow you to "compose"
> objects sim

Re: [Pharo-users] Installing SmaCC

[Dimitris Chloupis]

Those are interesting languages and probably better ideas than what I am
thinking. However they are not what I am talking about.

The language I am making is called "Magnatar"

Magnatar is not Smalltalk, but it is a Smalltalk trojan horse.

My main goals are

1) Create 100% readable C code, code that it looks like it was written by a
person and not automatically generated , leaving no room for suspicion
2) Keep as close to Smalltalk as I can
3) Map to C syntax , one to one
4) Implement a loose variant of OOP
5) Powerful macro system for source manipulation without the need for
header files
6) CMake integration (automate building which a headache in C/C++)

Essentially I am trying to make a language that can allow a smalltalker to
write C in Smalltalk and none noticing that he did. Hence why I talked
about a trojan horse. I got the live coding part covered already but I
would also like to use Pharo as the IDE of the language if I can. Also
because of (3) Magnatar will be purely statically typed not because I have
any love for static types but because it makes (3) far easier to
accomplish. So Magnatar wont be a Smalltalk implementation neither a
replacement for it.

This means also that Magnatar will be a way to extend Pharo on low level.
Writting  readable C using Smalltalky syntax for extensions instead of just
writting in C and then using Pharo's UFFI. Of course this will benefit
those that want to squeeze much more performance out of Pharo.

Magnatar also is not another language trying to take over the world but a
language I will use to write C code for a project I am working on which is
3d graphics and I need the full performance. So in the end it will be a
personal language.

Unfortunately this means no dynamic types at all, no GC , no VM, no
bytecodes, not intepretation of any sort, no image format. The only thing I
am keeping will be live coding. Also OOP will be basically super simple,
only c structs and c functions with a small API to allow you to "compose"
objects similarly to prototype based OOP but I am considering some syntax
for basic classes also. Again all these are under the prime goal of 100%
readable idiomatic C code. The rule is simple "if it cannot easily map to C
, it wont get in". So this is a highly focused language.

I have not found yet a language that compiles to readable C code although
there a lot of them that compile to unreadable C (nim, ECL, chicken scheme,
etc).

On Wed, Oct 17, 2018 at 8:37 AM H. Hirzel  wrote:

> The successor of Ni is 'Spry'
>
> https://github.com/gokr/spry
> http://sprylang.se/
>
> "Spry borrows homoiconicity from Rebol and Lisp, free form syntax from
> Forth and Rebol, the word of different types from Rebol, good data
> structure literal support from JavaScript and the general coding
> experience and style from Smalltalk. It also has a few ideas of its
> own, like an interesting argument passing mechanism and a relatively
> novel take on OO."
>
> --Hannes
>
> On 10/17/18, Ben Coman  wrote:
> > Have you looked at Ni?  (I only read about it)
> > http://goran.krampe.se/2015/09/16/ni-a-strange-little-language/
> >
> > cheers -ben
> >
> > On Wed, 17 Oct 2018 at 03:45, Dimitris Chloupis 
> > wrote:
> >
> >> Thank you Thierry , that was exactly what i was looking for :)
> >>
> >> On the subject of syntax, StrongTalk looks far more advanced compared to
> >> what I am aiming which is basically writting C code with Smalltalk like
> >> syntax. I am looking at this
> >>
> >> http://bracha.org/nwst.html
> >>
> >> Which describes some really impressive features. So I am aiming only for
> >> source to source compiler and not implementation of complex systems for
> >> incremental compilations , optional type system etc.
> >>
> >> On parsing strange code that is not much of an issue cause the project I
> >> am working on has pretty reasonable code and will probably offer a way
> to
> >> inline c code in case the parser fail. In any case my goals are small ,
> >> cause I dont have resources for complex implementations. Its also a
> >> language that will be designed solely for my needs and be offered open
> >> source for anyone else that may find it useful. In any case I am sure I
> >> will have many questions to ask :)
> >>
> >> I was looking into ANTLR , since the book I am reading on language
> design
> >> is using ANTLR but I rather implement this in Pharo. I used SmaCC when I
> >> was working for my Python bridge and I really liked it , mostly because
> >> it
> >> offers ready made syntax definitions for most popular languages. Which
> >> makes my life a lot easier.
> >>
>

Re: [Pharo-users] Installing SmaCC

[Dimitris Chloupis]

Thank you Thierry , that was exactly what i was looking for :)

On the subject of syntax, StrongTalk looks far more advanced compared to
what I am aiming which is basically writting C code with Smalltalk like
syntax. I am looking at this

http://bracha.org/nwst.html

Which describes some really impressive features. So I am aiming only for
source to source compiler and not implementation of complex systems for
incremental compilations , optional type system etc.

On parsing strange code that is not much of an issue cause the project I am
working on has pretty reasonable code and will probably offer a way to
inline c code in case the parser fail. In any case my goals are small ,
cause I dont have resources for complex implementations. Its also a
language that will be designed solely for my needs and be offered open
source for anyone else that may find it useful. In any case I am sure I
will have many questions to ask :)

I was looking into ANTLR , since the book I am reading on language design
is using ANTLR but I rather implement this in Pharo. I used SmaCC when I
was working for my Python bridge and I really liked it , mostly because it
offers ready made syntax definitions for most popular languages. Which
makes my life a lot easier.


On Tue, Oct 16, 2018 at 9:45 PM Thierry Goubier 
wrote:

> Hi Dimitris,
>
> Le 16/10/2018 à 19:39, Dimitris Chloupis a écrit :
> > yes i already said that i followed the instructions in the github repo
>
> Yes, by default that installation of SmaCC does not load all parsers
> (some of them are fairly large). However, most of them are in the
> downloaded repository, so you can load them independently.
>
> Otherwise, loading that way, should load everything:
>
> Metacello new
>baseline: 'SmaCC';
>repository: 'github://SmaCCRefactoring/SmaCC';
>load: #('Tools' 'Examples' 'Examples-Extra')
>
> Regarding your language question, I'd suggest two things:
>
> - Look at StrongTalk for a way to write Smalltalk with type declarations...
>
> - C parsers able to parse most strange C code one may encounter takes
> some work...
>
> Regards,
>
> Thierry
>
> > On Tue, Oct 16, 2018 at 8:18 PM H. Hirzel  > <mailto:hannes.hir...@gmail.com>> wrote:
> >
> > Refers to
> > https://github.com/SmaCCRefactoring/SmaCC
> >
> > which says
> >
> >   This is the port for Smalltalk/Pharo 1.3, 2, 3, 4, 5 and 6.
> >
> >
> > Installing a Development version of Pharo for the latest Pharo (with
> > no guarantees):
> >
> > Metacello new
> >  baseline: 'SmaCC';
> >  repository: 'github://SmaCCRefactoring/SmaCC';
> >  load
> >
> > On 10/16/18, H. Hirzel  > <mailto:hannes.hir...@gmail.com>> wrote:
> >  > What about trying
> >  >
> >  >
> >  > Metacello new
> >  > baseline: 'SmaCC';
> >  > repository: 'github://ThierryGoubier/SmaCC';
> >  > load
> >  >
> >  > This worked in Pharo 6.1 in November 2017
> >  >
> >  > On 10/16/18, Dimitris Chloupis  > <mailto:kilon.al...@gmail.com>> wrote:
> >  >> thanks for the info Peter , will give it a try :)
> >  >>
> >  >> On Tue, Oct 16, 2018 at 7:35 PM PBKResearch
> > mailto:pe...@pbkresearch.co.uk>>
> >  >> wrote:
> >  >>
> >  >>> Dimitris
> >  >>>
> >  >>>
> >  >>>
> >  >>> If you download the latest Moose Suite 6.1, you will have Pharo
> > 6.1 with
> >  >>> lots of extra packages, including SmaCC. The SmaCC includes
> > compilers
> >  >>> for
> >  >>> C, Smalltalk and Java, among others, but with little or no
> >  >>> documentation.
> >  >>> I
> >  >>> am not a SmaCC expert, so I can’t say whether it will do what
> >     you want,
> >  >>> but
> >  >>> at least it will give you a start. Moose also includes
> > PetitParser and
> >  >>> PP2,if you want to try other parsing approaches. Of course, the
> > Windows
> >  >>> version is 32-bit only, for reasons explained elsewhere in this
> > thread.
> >  >>>
> >  >>>
> >  >>>
> >  >>> HTH
> >  >>>
> >  >>>
> >  >>>
> >  >>> Peter Kenny
> >  >>>

Re: [Pharo-users] Installing SmaCC

[Dimitris Chloupis]

yes i already said that i followed the instructions in the github repo

On Tue, Oct 16, 2018 at 8:18 PM H. Hirzel  wrote:

> Refers to
> https://github.com/SmaCCRefactoring/SmaCC
>
> which says
>
>  This is the port for Smalltalk/Pharo 1.3, 2, 3, 4, 5 and 6.
>
>
> Installing a Development version of Pharo for the latest Pharo (with
> no guarantees):
>
> Metacello new
> baseline: 'SmaCC';
> repository: 'github://SmaCCRefactoring/SmaCC';
> load
>
> On 10/16/18, H. Hirzel  wrote:
> > What about trying
> >
> >
> > Metacello new
> > baseline: 'SmaCC';
> > repository: 'github://ThierryGoubier/SmaCC';
> > load
> >
> > This worked in Pharo 6.1 in November 2017
> >
> > On 10/16/18, Dimitris Chloupis  wrote:
> >> thanks for the info Peter , will give it a try :)
> >>
> >> On Tue, Oct 16, 2018 at 7:35 PM PBKResearch 
> >> wrote:
> >>
> >>> Dimitris
> >>>
> >>>
> >>>
> >>> If you download the latest Moose Suite 6.1, you will have Pharo 6.1
> with
> >>> lots of extra packages, including SmaCC. The SmaCC includes compilers
> >>> for
> >>> C, Smalltalk and Java, among others, but with little or no
> >>> documentation.
> >>> I
> >>> am not a SmaCC expert, so I can’t say whether it will do what you want,
> >>> but
> >>> at least it will give you a start. Moose also includes PetitParser and
> >>> PP2,if you want to try other parsing approaches. Of course, the Windows
> >>> version is 32-bit only, for reasons explained elsewhere in this thread.
> >>>
> >>>
> >>>
> >>> HTH
> >>>
> >>>
> >>>
> >>> Peter Kenny
> >>>
> >>>
> >>>
> >>> *From:* Pharo-users  *On Behalf
> Of
> >>> *Dimitris
> >>> Chloupis
> >>> *Sent:* 16 October 2018 15:40
> >>> *To:* Any question about pharo is welcome  >
> >>> *Subject:* [Pharo-users] Installing SmaCC
> >>>
> >>>
> >>>
> >>> Hey guys
> >>>
> >>>
> >>>
> >>> I downloaded the latest Pharo 6.1 64bit for Windows and tried to
> install
> >>> SmaCC through the catalog browser but it failed
> >>>
> >>>
> >>>
> >>> I did manage to install it following the instruction in the github repo
> >>> but I see that I am missing most parser packages.
> >>>
> >>>
> >>>
> >>> The languages I am interested are Smalltalk (which is included) and C
> >>> (if
> >>> possible C++ too) cause I will be creating a new language which will be
> >>> a
> >>> cross between C and Smalltalk (very similar to smalltalk syntax but
> with
> >>> the addtion of C types and no GC and dynamic typing and also a partial
> >>> implementation of OOP that is quite diffirent). My goal is compilation
> >>> of
> >>> my language to readable C code so the ability to parse also existing C
> >>> code
> >>> is needed.
> >>>
> >>>
> >>>
> >>> Any help is greatly appreciated , thanks :)
> >>>
> >>
> >
>
>

Re: [Pharo-users] Installing SmaCC

[Dimitris Chloupis]

thanks for the info Peter , will give it a try :)

On Tue, Oct 16, 2018 at 7:35 PM PBKResearch  wrote:

> Dimitris
>
>
>
> If you download the latest Moose Suite 6.1, you will have Pharo 6.1 with
> lots of extra packages, including SmaCC. The SmaCC includes compilers for
> C, Smalltalk and Java, among others, but with little or no documentation. I
> am not a SmaCC expert, so I can’t say whether it will do what you want, but
> at least it will give you a start. Moose also includes PetitParser and
> PP2,if you want to try other parsing approaches. Of course, the Windows
> version is 32-bit only, for reasons explained elsewhere in this thread.
>
>
>
> HTH
>
>
>
> Peter Kenny
>
>
>
> *From:* Pharo-users  *On Behalf Of 
> *Dimitris
> Chloupis
> *Sent:* 16 October 2018 15:40
> *To:* Any question about pharo is welcome 
> *Subject:* [Pharo-users] Installing SmaCC
>
>
>
> Hey guys
>
>
>
> I downloaded the latest Pharo 6.1 64bit for Windows and tried to install
> SmaCC through the catalog browser but it failed
>
>
>
> I did manage to install it following the instruction in the github repo
> but I see that I am missing most parser packages.
>
>
>
> The languages I am interested are Smalltalk (which is included) and C (if
> possible C++ too) cause I will be creating a new language which will be a
> cross between C and Smalltalk (very similar to smalltalk syntax but with
> the addtion of C types and no GC and dynamic typing and also a partial
> implementation of OOP that is quite diffirent). My goal is compilation of
> my language to readable C code so the ability to parse also existing C code
> is needed.
>
>
>
> Any help is greatly appreciated , thanks :)
>

Re: [Pharo-users] http://pharo.org/download | Pharo7 standalone?

[Dimitris Chloupis]

ah ok thats not a problem for me, thanks

On Tue, Oct 16, 2018 at 6:21 PM Esteban Lorenzano 
wrote:

> It just misses ONE module: Athens :)
>
> Esteban
>
>
> On 16 Oct 2018, at 17:11, Dimitris Chloupis  wrote:
>
> oh , thats confusing because Pharolauncher has a 64bit option
>
> On Tue, Oct 16, 2018 at 6:09 PM Cyril Ferlicot 
> wrote:
>
>>
>>
>> On mar. 16 oct. 2018 at 16:59, Dimitris Chloupis 
>> wrote:
>>
>>> I would love also to see a 6.1 standalone download for windows 64 bit,
>>> apparently the other platforms have 64 bit downloads. Is there a reason why
>>> its not available for Windows ?
>>>
>>>>
>>>>
>>>> The 64bit version of Windows is not yet finished.
>>
>> There is a version but it is missing modules.
>> --
>> Cyril Ferlicot
>> https://ferlicot.fr
>>
>
>

Re: [Pharo-users] http://pharo.org/download | Pharo7 standalone?

[Dimitris Chloupis]

oh , thats confusing because Pharolauncher has a 64bit option

On Tue, Oct 16, 2018 at 6:09 PM Cyril Ferlicot 
wrote:

>
>
> On mar. 16 oct. 2018 at 16:59, Dimitris Chloupis 
> wrote:
>
>> I would love also to see a 6.1 standalone download for windows 64 bit,
>> apparently the other platforms have 64 bit downloads. Is there a reason why
>> its not available for Windows ?
>>
>>>
>>>
>>> The 64bit version of Windows is not yet finished.
>
> There is a version but it is missing modules.
> --
> Cyril Ferlicot
> https://ferlicot.fr
>

Re: [Pharo-users] http://pharo.org/download | Pharo7 standalone?

[Dimitris Chloupis]

I would love also to see a 6.1 standalone download for windows 64 bit,
apparently the other platforms have 64 bit downloads. Is there a reason why
its not available for Windows ?

On Fri, Oct 5, 2018 at 12:50 PM Cyril Ferlicot 
wrote:

> On Fri, Oct 5, 2018 at 11:47 AM H. Hirzel  wrote:
> >
> > Hi Cyril
> >
> > This is fine for Linux   (e.g.
> >  curl get.pharo.org/64/70+vm | bash )
> >
> > But I see no indication on the page
> >  http://get.pharo.org/
> > how this works for Microsoft Windows.
> >
>
> Personally, I use it on git bash or cygwin or windows linux subsystem.
> I know it's not ideal but I get it to work like this.
>
> > --Hannes
> >
>
>
> --
> Cyril Ferlicot
> https://ferlicot.fr
>
>

[Pharo-users] Installing SmaCC

[Dimitris Chloupis]

Hey guys

I downloaded the latest Pharo 6.1 64bit for Windows and tried to install
SmaCC through the catalog browser but it failed

I did manage to install it following the instruction in the github repo but
I see that I am missing most parser packages.

The languages I am interested are Smalltalk (which is included) and C (if
possible C++ too) cause I will be creating a new language which will be a
cross between C and Smalltalk (very similar to smalltalk syntax but with
the addtion of C types and no GC and dynamic typing and also a partial
implementation of OOP that is quite diffirent). My goal is compilation of
my language to readable C code so the ability to parse also existing C code
is needed.

Any help is greatly appreciated , thanks :)

Re: [Pharo-users] MIDI IO

[Dimitris Chloupis]

There is PharoSound package from the catalog browser that I see it has some
MIDI capabilities but I do not know if it will work for you. I have used
Pharo Sound to playback audio files but never for MIDI.

As Guillermo said, UFFI is your best bet. Of course first you need to find
out how its done in C depending on which library you use.

I have done something like this but not in Pharo but Python. I own an
Andromeda A6 , probably the most powerful pure analogue non modular synth
of all time and even though it has thousands of parameters one can control
via its 72 knobs and lcd interface it lacks multi point envelopes. So I
made this app in Python using PyGame that I could draw multi point
envelopes and the software would play them back as soon as I played a note.

https://www.youtube.com/watch?v=4_DQWpViYEU

Excuse the crappy GUI it was a very early draft but it worked none the less
to my surprise although MIDI proved too slow to allow for quick envelops of
rapid changes. So I had to abandon the project and move on. That was back
in 2010 , before I started using Pharo or became aware of the existence of
Smalltalk.

https://github.com/kilon/vriareon


On Fri, Sep 21, 2018 at 2:34 PM Manuel Leuenberger 
wrote:

> Hi,
>
> I am currently investigating how to work with audio in Pharo, especially
> how to hook up Pharo to my synths or DAW using MIDI. I found that there is
> an old MIDI plugin for the VM, but apparently it has been discontinued due
> to OS changes (
> http://forum.world.st/Mac-OS-Cocoa-MIDI-Plugin-td4893691.html). Is there
> any setup that works for MIDI IO on OSX using Pharo 6/6.1?
>
> Cheers,
> Manuel
>
>

Re: [Pharo-users] Retina support in Pharo

[Dimitris Chloupis]

I may be wrong but last time I checked access to the OS Graphics API was
handled by the VM itself. There was a talk about decoupling that from the
VM and porting it to the image but no idea if it happened.

if it was the pragma primitive inside the method that means it calls native
code , the second case is using the UFFI which is the official FFI of
Pharo. The Pragma needs a VM rebuild , the UFFI does not. These are the two
ways that Pharo intefaces with native code (C/ObjectiveC etc).

So for starters you are going to need the VMMaker which is responsible for
building the VM , the good news is that it retains a lot of the live coding
characteristics and can even compile smalltalk to C (Slang) which is how it
keeps most of the code in Smalltalk rather than C.

If the Graphics API is still inside the VM then Eliot and other
contributors will be able to point you at the VM mailing list at the right
direction. If it is not then pharo-dev mailing list will most likely have
the developer/s responsible for porting it to the image and they will also
be able to point you to the right direction.

I dont think experience in smalltalk would play a big role here mainly
because its a C problem than a Smalltalk problem cause those libraries that
offer Retina support are written and meant to be used by C (ObjC) , this
applies for both primitive pragmas and UFFI. You experience with Cocoa is
going to be the crucial factor here, if you know how to do it in C , doing
it in Smalltalk is relative easy.

You may also be able to pintpoint the methods responsible for the rendering
by inserting a breakpoint in a window's draw method. The debugger should be
able to give you the stack back to the primitive/uffi call. Of course it
will require a bit of navigating around but such is the nature and curse of
coding.

On Tue, Sep 18, 2018 at 11:13 AM andyl  wrote:

> Hi,
>
> Has any work been done of this? If not, could someone point me in the right
> direction to start it, perhaps with a list of what is already known about
> the issue? I'd be willing to look at both MacOS and Windows HiDPI rendering
> at the same time.
>
> Presumably the 64 bit MacOS build is Cocoa based, so that would be the
> right
> starting point?
>
> Although I have decades of experience of the above platforms, I'm a
> relative
> novice with the Smalltalk libraries - so any hints as to how the rendering
> process currently hangs together (and how much is Smalltalk vs native
> rendering) would be really helpful.
>
> Regards,
> Andy.
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

Re: [Pharo-users] Pharo 7 and shortcuts

[Dimitris Chloupis]

Shortcuts have long been a thorn for Pharo, the lack of global state and
the fact that are hard coded. Colors and Themes had the same issue and it
was the effort Esteban who wanted to bring the dark theme that really
changed this. I suspect like Theme these are legacy Squeak stuff that are
not easy to fix.

Ideally shortcuts should be fully customisable with preset support
accessible from Pharo user settings. This way for example a vim user could
implement his own set of keys after his favorite editor. It would be nice
if that became a target for Pharo 7 or at least Pharo 8. No Pharo tool
should be allowed to manage its own shortcuts , not even third party tools.



On Sat, Jul 7, 2018 at 6:18 PM Norbert Hartl  wrote:

>
>
> > Am 07.07.2018 um 17:08 schrieb Cyril Ferlicot D. <
> cyril.ferli...@gmail.com>:
> >
> >> Le 07/07/2018 à 16:17, Ben Coman a écrit :
> >> Any seeming agreement may just have been the nay-sayers falling silent
> since
> >> there seemed little chance of having it changed when it came as a
> >> done-deal with Nautilus.
> >> Personally I tried to conform to using the double-sequence-shortcuts
> >> but could never get over the cumbersome feel of it,
> >> to the point where in Nautlius I actually stopped using shortcuts and
> >> reverted to using context menus.
> >>
> >> I guess lovers of the double-sequence-shortcuts are now in that boat.
> >> I'm not sure there was much discussion around Calypso using
> >> single-key-shortcuts.
> >> But I'm personally very happy with this behaviour change introduced by
> >> Nautlius was reverted.
> >> I'm glad to using shortcuts in the System Browser again.
> >>
> > For my part I'm not because before I could delete/rename/add a
> > package/class/protocol/method without the mouse but now it became much
> > harder with simple key shortcut since it works only on the focused pane.
> >
> > But I guess this kind of things depend on everyone.
> >
> > Maybe it could be good to be able to customize it via settings.
> >
> I don‘t understand anyway why keyboard shortcuts are dependent on a tool.
> Shouldn‘t there be an abstraction mapping between action and shortcut?
>
> Norbert
> >> cheers -ben
> >>
> >
> >
> > --
> > Cyril Ferlicot
> > https://ferlicot.fr
> >
>
>
>

Re: [Pharo-users] Pharo stable version with git support

[Dimitris Chloupis]

I have used Pharo with Git, for versioning source code and variable assets
, images and audio files using filetree and the git client of my choosing.
Git is super flexible , especially if you combine it with make files that I
also use to build my own custom pharo images together with pharo startup
scripts (the operate on the startup of a pharo image to check for
dependencies and incompatibilities with the image and then compensate for
any such problem).

Iceberg is great to make things easier and keep everything organized from
inside the image but I cannot stress enough that Iceberg SHOULD NOT be used
to avoid learning Git because in the end Git is extremely powerful ,
although sometimes not that elegant, its not easy to replace the existing
super powerful gui clients that exist for it and are used by millions of
developers worldwide. If you are on windows I recommend tortoiseGit cause
integrates elegantly with windows explorer and is very powerful. For MacOS
I recommend GitUp it has its own Undo functionality to quickly recover from
accidental mistakes.

All the above of course can be used together with Iceberg and there is
little reason for them to conflict because in the end , everything has to
follow the Git workflow and rules.

I have also tested these workflow for Gitlab (an open source alternative to
Github and probably the second most popular online repo website after
Github) and it works without any issues. The workflows is practically the
same.

On Sat, Jul 7, 2018 at 11:54 AM dario.trussa...@tiscali.it <
dario.trussa...@tiscali.it> wrote:

>
> Ciao,
> thanks.
>
> Hi Dario,
>
>> i'm interested to port all my code to new Pharo version that
>>> manage git support.
>>>
>>> I found information in pharo.org news, it talk of Pharo 6.1.
>>>
>>> But it run only on macOS 64bits o i can run it on Linux Ubuntu
>>> 16.04 LTS System?
>>>
>>> New information - update about it?
>>>
>>> Pharo 6.1 runs on 64bits, except for windows.
>
> OK,   i have setup a Pharo 6.1 image with Iceberg  update as
>> https://github.com/pharo-vcs/iceberg
>>
>> Now i'm "new"  to git support ..
>>
>
> Take into account that this is highly necessary. The version of Iceberg in
> Pharo 6.1 is just an old preview version.
> While Pharo works on 64 bits, Iceberg itself was not at that time, so
> upgrading is necessary to have that support.
>
>
> 1) OK, i have do the upgrade to: iceberg:dev-0.7
>
> "load iceberg"Metacello new
>   baseline: 'Iceberg';
>   repository: 'github://pharo-vcs/iceberg:v1.?';
>   onWarningLog;
>   load."Re-initialize libgit2"
> (Smalltalk at: #LGitLibrary) initialize.
>
> But it's the last version ?
>
> How i can understand what is the right version to update ?
>
> 2) for error i delete the..shared/pharo-local/iceber/git/iceberg
>  directory.
>
> i need to setup a new  pharo environment ?
>
>
>
>> I understand ???  that Iceberg has some limitations, it is not complete
>> ..
>>
>
> Iceberg already has pretty good support to manage pharo code.
>
> You'll find however that it does not manage (yet) non-pharo files. That
> is, if your repository has scripts, pictures or such kind of resources, you
> will have for now to edit and commit them from the outside (command line or
> another tool).
>
> The reasons for that are so far explained in here
> https://github.com/pharo-vcs/iceberg/blob/master/docs/The-Working-Copy(ies).md
>
> I would be grateful if someone explained to me how operatively I can
>> manage everything ... up to where I can do with Iceberg directly from Pharo
>> and how to operate from the shell on the git repository.
>>
>> Documentation in this sense?
>>
>
> Well, you have iceberg's wiki
>
> https://github.com/pharo-vcs/iceberg/wiki
>
> We are moving the documentation (hey, bit thanks to Tim Mackinon here!)
> to  the main repository so people can easy contribute to it.
> See https://github.com/pharo-vcs/iceberg/tree/master/docs.
> What is left is a sync mechanism between that directory and the wiki
> repository.
>
>>
>> My goal is to setup a environment for integrate Pharo development with
>> Gemstone GLASS Tode git support.
>>
>> Does anyone have experience in this sense?
>>
>
> That's not me, I hope you'll find somebody. But if you have any questions
> regarding Iceberg, don't hesitate to ask them!
>
>
> You intend at this support ?
>
> Thanks,
>
> Dario
>
>

Re: [Pharo-users] Some facts and figures about pharo gaining momentum?

[Dimitris Chloupis]

Pharo success in in the website, twitter and youtube channel.

Popularity wise the clear indication is community, I joined Pharo back in
2011 when it was already 3 years old and we had only one active mailing
list , pharo-dev, pharo-users were practically unused. Then we got so  many
new people we had to move to pharo-users and keep pharo-dev only for the
code going inside pharo standard distribution , then we grown even more and
we started using Slack. Then I had the idea to move us to Discord, our
Discord server ended up having way more channels than Slack. So we are
definetly growing , how much is the real hard thing to determine.

Even if you take Github to account you will have to ignore all forks,
because many Github users, including me, tend to use forks as mere
bookmarks. So one's forks the project and ends never using it but the fork
will also report commits that coming from the original repo. Coding like
anything else in live is too complex to describe in numbers and stats.

I think the best way to sell any language is to do your research, the
person or people who you want to convince, you have to know what they are
interested about, web dev, databases, embeded computing etc. Instead of
stats provided them with libraries and documentation. Anyone come making a
super cool project but usually for a developers it far important to know
that the "cool" language someone else is praising actually has the
libraries you may need.

I for example don't care at all for web dev, I don't even like it, or
databases, but I love graphics and sound. So I won't care for Seaside,
PharoJS etc. But Pharo Sound and Woden is two projects that are very
interesting to me. Like a recent video publiced by Pharo in youtube about
people using Woden (a 3d graphics engines made in Pharo) to do VR. If I
never used Pharo before that definetly would tempt it, taking into account
that VR is not even that widely available even with most popular languages.

Take for example Ruby, none really cared that no company made an amazing
project in the language, what they cared was that a solo dev decided to
make that amazing web dev library called Ruby On Rails and then , BOOM,
Ruby exploded in popularity. Python's also popularity is purely on its
library set solely, third party. Java is not the rule , it actually the
exemption , merely for the practical fact that very few language can afford
support from big companies. Python's creator did not even intend to make a
programming language, its just made it to automate command line tasks
because he was not so much into the Bash alternatives. He tried to even
stop them from using it as C++ alternative, too late, Python is the
standard in the scientific community. Basic started as just a language to
teach kids and then it took over the world via home computers. People
making pro apps in Basic, ridiculous, hello Visual Basic. Smalltalk started
mainly as research project. Lisp as a purely theoretical mathematical
concept.

So my advice is not to worry much about it, just find the libraries that
people need in Pharo and that will be far more than enough to convince them
to take the plunge. Available project in any language are nothing more than
a tiny fraction of the language's potential, the big hot potatoes are
performance (none likes slow code), libraries (everyone is lazy) and
documentation (none likes to decipher other's people code).

People don't hide the fact that they use Pharo , afterall that's the whole
idea of this mailing list to share your success and failures with Pharo and
ask questions about it.

But you don't mean much to sell a language , afterall one thing all
language popularity websites agree on is that almost 50% of the code out
there is written for tiny project in languages none cares about. I am
talking about languages like Pharo that end up having a popularity way
bellow 0.01% . There is a reason we have thousands of languages to choose
from and it ain't popular projects ;)

On Thu, Jul 5, 2018 at 10:01 PM Andrei Stebakov  wrote:

> Thanks, Kilon for such an insightful answer. Lots of stuff to think about.
> I guess what I was waiting for is some success stories (which we already
> have on the website), but coming from you guys as consultants saying
> something like: "oh, this year I have more projects than last year" or "now
> my network of Smalltalk aware customers is that much bigger" or "a friend
> of mine who works in company XYZ says that after some consideration they
> started to use Pharo for micro services instead of Java".
> I know, it's hard to measure the success level in numbers (other than the
> example you gave with github stats), more like the word of mouth kind of
> thing.
> Another metrix could be the subscription rate for this mailing list, since
> chances are that most of new Pharo users would be on it and the
> acceleration of that rate would definitely say something about Pharo
> success. Wondering if we have access to that data.
> Thanks for your 

Re: [Pharo-users] How to LAN feature

[Dimitris Chloupis]

On Sun, May 6, 2018 at 1:48 PM Hilaire  wrote:

> Hi,
>
> I am looking for advices on a feature I want to develop for Dr. Geo.
>
> The need takes place in a LAN, for example in a School computer lab.
>

I think that even in the case of a LAN you can still do it via internet
using something like github or dropbox. Many of those online tools work on
an account basis and Pharo already offers some support for Github.

If it has to be a LAN and the internet is a no go then another choice would
be to have the "server" which probably will be the teacher access to the
truter and retriever the IPs directly, even if the ip changes the
connection can be identified by name and of course the router will provide
the ips and names of all connections to it. I have not tried from Pharo but
I am assuming it should be doable because the router can be access via an
internet browser for their setup and settings.

Format wise you could use something like STON , or if you rely of raster
graphics (JPEG, PNG) , fuel could be a better choice for binary formats and
eliminate any loss of performance while loading scetches remotely.

Nowdays it has become the norm to identify people through popular accounts
like Google (gmail), Facebook, iCloud, Microsoft Account, Twitter etc.

In the case of dropbox you get also synchronisation for free which will
give students immediate access not only to sceteches by teachers but all
other students too because dropbox supports shared folders and you wont
have to actively share each individual folder because those folder do this
automagically for you.

Dropbox also stores the version of the files for up to 30 days and of
course its free, unless the scetches demand much more than 2 GBs which if
they are anything like SVG they should not.

Re: [Pharo-users] Personal Programming onPharo

[Dimitris Chloupis]

correction I mean to say
"Pharo is far from perfect, if it was I would still be coding in it but
none the less, stability is definetly NOT one of its main problems."

On Tue, May 8, 2018 at 2:37 PM Dimitris Chloupis <kilon.al...@gmail.com>
wrote:

> On Mon, May 7, 2018 at 1:43 PM Trygve Reenskaug <tryg...@ifi.uio.no>
> wrote:
>
>> Please tell me when Java, C, C++, etc programs stopped working because
>> their runtime systems had changed.
>> Please tell me when Java, C, C++, etc compilers stopped compiling old
>> code because the languages had changed.
>>
>
> 1) C and C++ do not have runtime systems, only Java has. The closest to C
> with a runtime system is C# that has .NET.
> 2) Pharo does not have a runtime system, it has a live coding enviroment
> which goes far beyond the demands of a runtime system which is usually
> compiler + intepreter + VM + standard library.
> 3) Pharo language changes even less often than C/C++ and Java. Even though
> C/C++ and Java are too afraid to change because of the panic they will
> cause to millions of developers too busy maintaining ugly highly unstable
> code that those languages are so prone at. Pharo language changes even less
> mainly because its far less minimal , you only need 6 lines of code to
> describe the entire syntax the rest is implemented as libraries which also
> rarely change as well.
>
> 99.9% of Pharo issues/bugs are IDE related or some advanced software
> development tool and new library that goes far beyond the scope of the
> language and its "standard" library.
>
> So technically speaking if we were to compared Pharo with C/C++ and Java
> on equal grounds as languages , plus stanard library , plus vm etc , Pharo
> is stellar they are a big pile of mess which is rapidly replaced by dynamic
> languages.
>
> It was just 2 decades ago when C++ was the undisputed king of software
> development and using another language besides VB was seen as nothing less
> than insane. Nowdays people have long abandoned ship and VB is seen as
> nothing more than an abomination.
>
> Its ironic you mentioned Java because Java exist for one thing and one
> thing only , to kill C++. Did not manage to succeed but it did manage to
> steal away half of the developers on the premise alone that Java is far
> less likely to create unstable code than C/C++.
>
> The irony of course did not stop there and pretty much every modern
> dynamic language (modern static languages are an extremely rare breed in
> comparison) use the same argument or far more stable , much easier to debug
> and maintaine code.
>
> I have coded in Pharo for 6 years and nowdays I daily deal with C++
> (mainly because of graphics code through OpenGL, Cuda etc) and I can tell
> you stability wise there is not even a comparison. Sure the language and
> its library can be stable but what use is that to me when the code is so
> prone to creating a ton of problem I have to ellude with the acrobatic
> skills of spiderman ?
>
> Pharo is far from perfect, if it was I would still be coding in it but
> none the less, stability it definetly one of its main problems. Everything
> crash and burns at some point and frankly Pharo does it far more elegantly
> than any other language I have ever used and far less so.
>

Re: [Pharo-users] Personal Programming onPharo

[Dimitris Chloupis]

On Mon, May 7, 2018 at 1:43 PM Trygve Reenskaug  wrote:

> Please tell me when Java, C, C++, etc programs stopped working because
> their runtime systems had changed.
> Please tell me when Java, C, C++, etc compilers stopped compiling old code
> because the languages had changed.
>

1) C and C++ do not have runtime systems, only Java has. The closest to C
with a runtime system is C# that has .NET.
2) Pharo does not have a runtime system, it has a live coding enviroment
which goes far beyond the demands of a runtime system which is usually
compiler + intepreter + VM + standard library.
3) Pharo language changes even less often than C/C++ and Java. Even though
C/C++ and Java are too afraid to change because of the panic they will
cause to millions of developers too busy maintaining ugly highly unstable
code that those languages are so prone at. Pharo language changes even less
mainly because its far less minimal , you only need 6 lines of code to
describe the entire syntax the rest is implemented as libraries which also
rarely change as well.

99.9% of Pharo issues/bugs are IDE related or some advanced software
development tool and new library that goes far beyond the scope of the
language and its "standard" library.

So technically speaking if we were to compared Pharo with C/C++ and Java on
equal grounds as languages , plus stanard library , plus vm etc , Pharo is
stellar they are a big pile of mess which is rapidly replaced by dynamic
languages.

It was just 2 decades ago when C++ was the undisputed king of software
development and using another language besides VB was seen as nothing less
than insane. Nowdays people have long abandoned ship and VB is seen as
nothing more than an abomination.

Its ironic you mentioned Java because Java exist for one thing and one
thing only , to kill C++. Did not manage to succeed but it did manage to
steal away half of the developers on the premise alone that Java is far
less likely to create unstable code than C/C++.

The irony of course did not stop there and pretty much every modern dynamic
language (modern static languages are an extremely rare breed in
comparison) use the same argument or far more stable , much easier to debug
and maintaine code.

I have coded in Pharo for 6 years and nowdays I daily deal with C++ (mainly
because of graphics code through OpenGL, Cuda etc) and I can tell you
stability wise there is not even a comparison. Sure the language and its
library can be stable but what use is that to me when the code is so prone
to creating a ton of problem I have to ellude with the acrobatic skills of
spiderman ?

Pharo is far from perfect, if it was I would still be coding in it but none
the less, stability it definetly one of its main problems. Everything crash
and burns at some point and frankly Pharo does it far more elegantly than
any other language I have ever used and far less so.

Re: [Pharo-users] Please rejoin Discord

[Dimitris Chloupis]

Because I posted a new link it was misinterpreted that the old one did not
work which is not the case. Yeah changing it back to the old one is the
right choice. I created the new one only for convenience but as I said we
already have a ton of invite links.

In any case the old one will remain and wont bet changed, unless
Dicscord decides something stupid which I doubt will do because already too
many people (outside our community) that use Discord depend on the invite
links not to change and remain the same.

So all is good :)

On Sun, Mar 11, 2018 at 9:43 PM Stephane Ducasse <stepharo.s...@gmail.com>
wrote:

> Ok now I do not understand why the invite changed on the pharo web
> site (and I do not like the here instead of the full name) because we
> have to hover to get the information.
>
> On Sun, Mar 11, 2018 at 7:30 PM, Dimitris Chloupis
> <kilon.al...@gmail.com> wrote:
> > if you provide me the specific link of the invitation you are referring
> to,
> > I can verify it for you that has not changed
> >
> > Our server currently has 26 invites with no expiration date. 2 of them
> are
> > created by me.
> >
> > But yes if an invite is without expiration date it means it won't get
> > deleted.
> >
> > The most likely scenario is that you are using an invite created by
> Esteban
> > (@Estebanlm), because it has been used 871 times. That invite has not
> > changed and is the invite ending with "Sj2rhxn" and indeed it has no
> > expiration date, which means it will "never" change. Neither any other of
> > the 26 invites.
> >
> >
> >
> >
> > On Sun, Mar 11, 2018 at 8:07 PM Stephane Ducasse <
> stepharo.s...@gmail.com>
> > wrote:
> >>
> >> did the invitation changed?
> >> Because we will have to update books flyers and others.
> >> So is there a way to keep the invitation link stable?
> >>
> >> Stef
> >>
> >> On Sat, Mar 10, 2018 at 11:48 AM, Dimitris Chloupis
> >> <kilon.al...@gmail.com> wrote:
> >> > Hey guys after my mistake we got "hacked" and someone banned all our
> >> > members
> >> > in Discord
> >> >
> >> > I have revoked all the bans but you will have to rejoin . Existing
> join
> >> > links are still valid , if you dont have one here is one
> >> >
> >> > https://discord.gg/gtKeHne
> >> >
> >> > My apologies for this inconvenience, I am still exploring all possible
> >> > threats to make sure this never happens again.
> >>
> >
>
>

Re: [Pharo-users] Please rejoin Discord

[Dimitris Chloupis]

if you provide me the specific link of the invitation you are referring to,
I can verify it for you that has not changed

Our server currently has 26 invites with no expiration date. 2 of them are
created by me.

But yes if an invite is without expiration date it means it won't get
deleted.

The most likely scenario is that you are using an invite created by Esteban
(@Estebanlm), because it has been used 871 times. That invite has not
changed and is the invite ending with "Sj2rhxn" and indeed it has no
expiration date, which means it will "never" change. Neither any other of
the 26 invites.




On Sun, Mar 11, 2018 at 8:07 PM Stephane Ducasse <stepharo.s...@gmail.com>
wrote:

> did the invitation changed?
> Because we will have to update books flyers and others.
> So is there a way to keep the invitation link stable?
>
> Stef
>
> On Sat, Mar 10, 2018 at 11:48 AM, Dimitris Chloupis
> <kilon.al...@gmail.com> wrote:
> > Hey guys after my mistake we got "hacked" and someone banned all our
> members
> > in Discord
> >
> > I have revoked all the bans but you will have to rejoin . Existing join
> > links are still valid , if you dont have one here is one
> >
> > https://discord.gg/gtKeHne
> >
> > My apologies for this inconvenience, I am still exploring all possible
> > threats to make sure this never happens again.
>
>

Re: [Pharo-users] Please rejoin Discord

[Dimitris Chloupis]

Hmm thats weird that you guys lost your admin roles, but not entirely,
maybe the hack is responsible, no problem will add you back.

I removed the authorisation of any third party apps and I am closing any
potential security hole. I think I got them all covered but will stick
around and keep ownership of the server to make sure nothing like this
happens again.

Please note that our message history is unharmed and nothing has been lost.
I have however restored permissions to all channels so any channels admins
may want to restore them back to their preference, if you are no longer a
channel admit please drop me a message in here or Discord.

The good news out of this experience is that I was completely blown away by
the sheer numbers we had so far. It felt almost a year ago, when people
frowned on the idea of leaving Slack for Discord (not that I blame them)
and now we have 1000 members. This is an opportunity to see how many of
those 1000 are active members. Obviously a minority of them but still in
terms of Discord numbers that is a pretty big community.

Another proof of the growing popularity of Pharo.

By the way being admin is not a responsibility, it does not come with
strings attached. I make people admins in the case when I or Esteban are
not around and cannot help , so people can help each other if they are
available and willing.

Do not feel any guilt if you are not able or willing to do any admin work.
If you just help a member even one time that is reason enough to be in
admin position. Both Esteban and I have been able to maintain the server
with ease and the fact that 11 hours passed was that I sleeping (yeas I do
sleep, sometimes :D ) took me some time to respond. Overall managing the
server requires minor attention and this is the first issue we have
experienced so far.

So all is good and thank you all for making Pharo better and helping each
other, keep rocking :)

On Sat, Mar 10, 2018 at 1:34 PM p...@highoctane.be <p...@highoctane.be>
wrote:

> Same here, no more admin
>
> On Sat, Mar 10, 2018 at 12:15 PM, Clément Bera <bera.clem...@gmail.com>
> wrote:
>
>> I think the roles got changed I am no longer admin (Note that it does not
>> really matter since I did not do much admin work but still)
>>
>> On Sat, Mar 10, 2018 at 11:48 AM, Dimitris Chloupis <
>> kilon.al...@gmail.com> wrote:
>>
>>> Hey guys after my mistake we got "hacked" and someone banned all our
>>> members in Discord
>>>
>>> I have revoked all the bans but you will have to rejoin . Existing join
>>> links are still valid , if you dont have one here is one
>>>
>>> https://discord.gg/gtKeHne
>>>
>>> My apologies for this inconvenience, I am still exploring all possible
>>> threats to make sure this never happens again.
>>>
>>
>>
>>
>> --
>> Clément Béra
>> Pharo consortium engineer
>> https://clementbera.github.io/
>> https://clementbera.wordpress.com/
>> Bâtiment B 40, avenue Halley 59650
>> <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0+Villeneuve+d+Ascq=gmail=g>Villeneuve
>> d
>> <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0+Villeneuve+d+Ascq=gmail=g>
>> 'Ascq
>> <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0+Villeneuve+d+Ascq=gmail=g>
>>
>
>

[Pharo-users] Please rejoin Discord

[Dimitris Chloupis]

Hey guys after my mistake we got "hacked" and someone banned all our
members in Discord

I have revoked all the bans but you will have to rejoin . Existing join
links are still valid , if you dont have one here is one

https://discord.gg/gtKeHne

My apologies for this inconvenience, I am still exploring all possible
threats to make sure this never happens again.

Re: [Pharo-users] [ANN] Python3Generator and MatplotLibBridge

[Dimitris Chloupis]

yeah I am afraid I understood exactly what you meant because at first that
was my initial desire when I made Atlas.

Essentially you want auto mapping of Python objects to Pharo, so you wont
have to deal with Python and do everything from inside the Pharo image. So
essentially reading and writing Python objects as if they were Pharo
objects.

Take a more careful look to my reply, you will see that is exactly what I
am focusing on.

Unless you dont mean automatically and mean manually, which in that case is
something I have already done.

I used SmaCC , as already pointed out it already maps python syntax to
pharo objects. So lucky for you this work is done for you. But you still
need to traverse the object tree to do the remapping and there lies the
tricky part for all the reasons I already explained in the previous answer
,again assuming you want to do this automagically.

Ironically one would expect to be relative easy to convert Python objects
to Pharo objects , while making Python able to live code , incredible hard.

After trying both I can tell you that turning Python to a live coding
environment was a walk in the park. Mapping objects is making me have
nightmares.

You will be lucky if the objects are pure data of primitive format, this
means, floats, strings, integers and all the other usual suspects. In that
case you dont even need to worry about conversion you just export to JSON
and import back to Pharo and voila you have objects that are both Pharo and
Python compatible. JSON is such a common format that can be used any way
you like, you want to write it to a file, share it in memory, transmit it
through socket, anything you like its possible.

But then moment the Python objects maps to some exotic object with
dependencies  to C code, welcome to dependency hell, fasten your seat belt
its going to be a bumpy ride.

On Wed, Jan 10, 2018 at 5:59 PM Julien <julien.delplan...@inria.fr> wrote:

> Even if I learned things from your answer, I think you misunderstood what
> I was talking about. :p
>
> What I want is a mechanism to describe python’s objects from Pharo and
> being able to:
> 1. Serialise those objects from Python
> 2. Send those object to Pharo (whatever the way it is done: socket, write
> in a file from python and read from Pharo, etc…)
> 3. Materialize those serialised Python’s objects as Pharo objects.
>
> Basically, I want to be able to transfer data from Python to Pharo easily.
>
> Something better than getting the values held by Python objects by parsing
> their String representation « by hand »... :-)
>
> Julien
>
> ---
> Julien Delplanque
> Doctorant à l’Université de Lille 1
> http://juliendelplanque.be/phd.html
> Equipe Rmod, Inria
> Bâtiment B 40, avenue Halley 59650
> <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve%C2%A0d'Ascq=gmail=g>
>  Villeneuve
> <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve%C2%A0d'Ascq=gmail=g>
>  d'Ascq
> <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve%C2%A0d'Ascq=gmail=g>
> Numéro de téléphone: +333 59 35 86 40 <+33%203%2059%2035%2086%2040>
>
> Le 10 janv. 2018 à 16:43, Dimitris Chloupis <kilon.al...@gmail.com> a
> écrit :
>
>
>
> On Mon, Jan 8, 2018 at 5:50 PM Julien <julien.delplan...@inria.fr> wrote:
>
>> Beware that no mechanism to get back values from Python is defined for
>> now (except if you just want the String
>> representation of those objects, then you can get that if you use atlas).
>>
>> I’d like to have that but it is not easy. I would like a way to describe
>> how to map Python’s objects to Pharo’s objects
>> from Pharo and to have the code to do that in Python side generated
>> automatically but some thinking is needed…
>>
>> Julien
>>
>
> It won't be easy
>
> I have noted in the past the similarities between Pharo and Python but
> here there is also a massive difference.
>
> In Pharo we have the mentality of reinventing many stuffs ourselves so the
> systems is based to a very large extend on Pharo that runs on very
> efficient JIT VM. Almost everything is Pharo code.
>
> Python on the other hand is the exact opposite, Python runs on an
> extremely slow VM but more than 50% of its code in written in C, Python
> itself or its third party libraries.
>
> So the irony is that even though in theory and practice Python code is one
> of the slowest , in actual scenarios its one of the fastest able to
> outperform even Java to a very large extend because its libraries that are
> made for high performance like Numpy are predominately C code. Pretty much
> every C or C++ library has wrappers for Python which is what made it so
> popular. Hence the reason behind the insanity when it comes to top
> perf

Re: [Pharo-users] [ANN] Python3Generator and MatplotLibBridge

[Dimitris Chloupis]

On Mon, Jan 8, 2018 at 5:50 PM Julien  wrote:

> Beware that no mechanism to get back values from Python is defined for now
> (except if you just want the String
> representation of those objects, then you can get that if you use atlas).
>
> I’d like to have that but it is not easy. I would like a way to describe
> how to map Python’s objects to Pharo’s objects
> from Pharo and to have the code to do that in Python side generated
> automatically but some thinking is needed…
>
> Julien
>

It won't be easy

I have noted in the past the similarities between Pharo and Python but here
there is also a massive difference.

In Pharo we have the mentality of reinventing many stuffs ourselves so the
systems is based to a very large extend on Pharo that runs on very
efficient JIT VM. Almost everything is Pharo code.

Python on the other hand is the exact opposite, Python runs on an extremely
slow VM but more than 50% of its code in written in C, Python itself or its
third party libraries.

So the irony is that even though in theory and practice Python code is one
of the slowest , in actual scenarios its one of the fastest able to
outperform even Java to a very large extend because its libraries that are
made for high performance like Numpy are predominately C code. Pretty much
every C or C++ library has wrappers for Python which is what made it so
popular. Hence the reason behind the insanity when it comes to top
performance Python being second only to C++.

So you will have not only map the Python oobjects  to Pharo object but also
map the C code. Even though this may sound impossible the good news is that
Python libraries, having the extension pyd , are basically DLLs made
supporting a specific API which is very minimal in design. Similar to our
UFFI , the only major difference is that library is responsible of keeping
track of the reference count, which is used by Python GC to erase no longer
used objects from memory. Which is a very simple increase and decrease.

So not only you will have to remap the Python objects but also DLLs as
well.

To add salt to the wound , Python has something that Pharo does not.
Multiple inheritance. Which of course makes your goal even harder. Python
coder's generally avoid multiple inheritance as much as we avoid overriding
doesNotUnderstand , but its a feature they use none the less.

Hence why I did not even consider trying something like that. Plus you will
be gaining no advantage because C code is unportable to Pharo anyway. Sure
we have Slang , but Slang is extra careful with types which normal Pharo
code does not. You will be losing performance because yes porting to Pharo
as much as JIT VM may be great , its no much for Python libraries that
merely leverage C. Plus you will have to update it each time the library
changes etc.

So my conclusion was that the most efficient way was to let Python execute
the library and just manipulate Python.

It's much easier to do the exact opposite, which goes against our mentality
, and port your Pharo objects to Python objects. Because a) your objects
will always be far less than a complete library and system b) you wont have
to worry about C code because you wont have any c) all the other negatives
I mention , disappear.

It usual case of not being able to have your cake and eat it too.

Re: [Pharo-users] [ANN] Python3Generator and MatplotLibBridge

[Dimitris Chloupis]

Ah ok so you want to target the AST specifically, I see now.
Yeap I did not implement any security measure for Atlas because the goal
was local and not remote execution. Yes indeed the socket connects directly
to 127.0.0 port 4000.So Atlas is preconfigured to work locally. I think
safety is something that the developer must control to make it specific to
the nature of the code. Plus I am no web dev. Plus if OS security is
breached to gain access to Atlas, the user is already in a deep mess, Atlas
will be the least of his concerns.

If my assumption is correct and you execute python code by writing it to a
python file and then executing the module, note that this approach is
actually much slower to the socket approach. Which is why I did not go for
it in the first place. Sockets work similar to files but use memory and
thus do not write to hard disk and so they work faster. Which is why
sockets are so popular for local IPC as well. I am not sure if Pipes as
faster but I doubt it.

Memory mapped files are much safer and much faster, which is why shared
memory is the most popular IPC for local comunication , the hacker would
have to hack the memory low level style because memory mapped files are
controlled by the OS kernel and is basically what is used for shared
libraries, the very popular DLLs on windows , dylib on MacOS, and so on
Linux. If performance becomes a serious issue for you and you want the
safest way to do local IPC , I highly recommend this approach.

But if you are happy with your current solution, there is no need to modify
your code.

On Fri, Jan 5, 2018 at 9:09 PM Julien <julien.delplan...@inria.fr> wrote:

>
> Le 5 janv. 2018 à 17:15, Dimitris Chloupis <kilon.al...@gmail.com> a
> écrit :
>
>
>
>
>>
>> Python3Generator allows to generate a Python 3 AST programatically. So
>> basically you have objects that represent Python 3 AST nodes and some
>> messages in top of that to make the generation of the AST easier from Pharo.
>>
>> E.g.
>>
>> ast := 'print' asP3GIdentifier callWith: #('Hello world').
>>
>> ast inspect
>>
>
> yes buy why ? Why you want to generate objects , Python AST nodes are
> already python objects and you already generate AST nodes each time you
> execute python code.
>
> Using the Atlas syntax your above example would be simpler
>
> py = ATLPyParser new
>
> py print:'("Hello World")'
>
> Is there an advantage using your own syntax ? Is there any advantage of
> direct access to Python AST?
>
>
> In MatplotLibBridge I do some checking/optimisations on the AST generated
> by high-level API objects (e.g. for optimisation avoid importing a package
> twice).
> With an AST it is easy with basic Atlas I think this is not possible.
> Having an AST allow to do stuff on the code to execute before executing it
> and this easily
> and maintainable (i.e. not using regexes).
>
>
>> 
>>
>> If you have a look at the readme on GitHub you will see more complexe
>> examples.
>>
>> Yes I did take a look but I still did not know why you bother generating
> identifiers for each python command manually when ATLPyParser does this
> automatically for you.
>
> For example you have this example
>
> "Use and initialize the FFI interpreter."
> P3GInterpreter useFFIInterpreter.
> P3GInterpreter current pathToPython: '/usr/bin/python3'.
>
> instr := P3GInstructionsList new.
>
> json := 'json' asP3GIdentifier.
> file := 'file' asP3GIdentifier.
> os := 'os' asP3GIdentifier.
>
> instr addAll: {
> json import.
> os import.
> file <- ('open' asP3GIdentifier callWith: #('/tmp/osp3g.json' 'w')).
> (file=>#write) callWith: { (json=>#dumps) callWith: {{
> 'os' -> (os=>#name).
> 'uname' -> (os=>#uname) call 
> } asDictionary} }.
> ((file=>#close) call)
> }.
>
> instr execute.
>
>
> Using the ATLPyParser of Atlas would have been much simpler
>
> py = ATLPyParser
>
> Atlas sendMessage:'import json,os'
>
> py
> file:'= open("/tmp/osp3.json","w")';e;
> file write:'(json.dump({"os":os.name,"uname":os.uname}))';e;
> file close;e.
>
> Or the point is to fully parse pharo syntax to python ?
>
>
> What I would like to experiment for fun is translating Pharo Smalltalk to
> Python 3.
>
> And as said before with your technique you can not modify the AST easily
> before sending it to Python.
>
>
>
>
>> I wanted that to avoid the user having to set up a Python server
>> listening on a socket when it is not needed to get data from Python.
>>

Re: [Pharo-users] [ANN] Python3Generator and MatplotLibBridge

[Dimitris Chloupis]

>
> Python3Generator allows to generate a Python 3 AST programatically. So
> basically you have objects that represent Python 3 AST nodes and some
> messages in top of that to make the generation of the AST easier from Pharo.
>
> E.g.
>
> ast := 'print' asP3GIdentifier callWith: #('Hello world').
>
> ast inspect
>

yes buy why ? Why you want to generate objects , Python AST nodes are
already python objects and you already generate AST nodes each time you
execute python code.

Using the Atlas syntax your above example would be simpler

py = ATLPyParser new

py print:'("Hello World")'

Is there an advantage using your own syntax ? Is there any advantage of
direct access to Python AST?

>
> [image: Capture d’écran 2018-01-05 à 13.06.41.png]
>
> If you have a look at the readme on GitHub you will see more complexe
> examples.
>
> Yes I did take a look but I still did not know why you bother generating
identifiers for each python command manually when ATLPyParser does this
automatically for you.

For example you have this example

"Use and initialize the FFI interpreter."
P3GInterpreter useFFIInterpreter.
P3GInterpreter current pathToPython: '/usr/bin/python3'.

instr := P3GInstructionsList new.

json := 'json' asP3GIdentifier.
file := 'file' asP3GIdentifier.
os := 'os' asP3GIdentifier.

instr addAll: {
json import.
os import.
file <- ('open' asP3GIdentifier callWith: #('/tmp/osp3g.json' 'w')).
(file=>#write) callWith: { (json=>#dumps) callWith: {{
'os' -> (os=>#name).
'uname' ->
(os=>#uname) call } asDictionary} }.
((file=>#close) call)
}.

instr execute.


Using the ATLPyParser of Atlas would have been much simpler

py = ATLPyParser

Atlas sendMessage:'import json,os'

py
file:'= open("/tmp/osp3.json","w")';e;
file write:'(json.dump({"os":os.name,"uname":os.uname}))';e;
file close;e.

Or the point is to fully parse pharo syntax to python ?



> I wanted that to avoid the user having to set up a Python server listening
> on a socket when it is not needed to get data from Python.
>
> Yep, but if I want to get value from Python into Pharo, I want to have
> them as Pharo objects so as you said some conversion has to be made which
> means more work.
>

Actually the server is setup at Pharo side, Python side is merely a client.
All the heavy lifting is taking place via Pharo. The user does not need to
do anything , its automatic.  But yeah if you want to completely liberate
yourself from sockets I can understand that, though I do not understand
why, you use sockets every time you access the internet and they are really
fast. So its not as if you can avoid socket generation.

Re: [Pharo-users] [ANN] Python3Generator and MatplotLibBridge

[Dimitris Chloupis]

Well done, great to see my code be reused for new project. I am happy to
see people take it one step further.

What exactly your code offers additional to my code ? Is there is something
special you do with it?


> There is a concept of « Interpreter » in this framework. Basically, an
> interpreter is an object to which you provide strings containing Python 3
> code and that execute it.
>
> There is a FFI interpreter which writes the python code in a file on the
> file system and uses the int system(char *) function to make python execute
> the file. It also redirect stderr to a file and read that file after
> execution in order to have eventual execution errors.
>

You don't really need this approach. The reason why I did not add this
feature in Atlas is because the way that Python import its files is
basically normal execution.

So each time you

import mymodule

what you do is you execute mymodule. Basically Python does the same thing
with execution when it does a import. This is why we need the if main thing
to detect whether the module execution happened because of import or
because it was executed directly (via terminal, or double click).

So in case of Atlas all you have to do is put your code in a python module
and import then module from atlas with sendMessage: 'import mymodule'.


> There is a Atlas interpreter which uses the Atlas project from Kilon.
> Atlas makes Python and Pharo talk trough sockets. So this is what you want
> I guess. The thing is, if I want to send data from Python Pharo, I would
> use the Atlas interpreter and serialise data to send to Pharo through a
> socket as JSON for example. But for Matplotlib I do not need to read
> Python’s value so I did not implemented that. Nevertheless, it could be
> cool to have this ability to get Python’s data in Pharo because we could
> use Numpy or others Python modules for which getting Python's is important.
>
>
Atlas provide this ability via getValue: message. There is a catch , what
you get is always strings. So that means if you use a complex Python object
you will have to convert that to some form of string format that clearly
represents the data . JSON could be a good candidate here because both
Python and Pharo support this. I have created a very basic template Pharo
object that parses strings to Pharo objects as an example that I have
included but still its going to be tricky especially with Numpy because it
all happens at C level and not Python level for performance reasons. Still
its not that hard to do if you really need this feature which in your case
you don't.


> Another interesting thing when communicating through sockets between two
> different languages is: How do you manage callbacks? For example I would
> like to be able to make Python execute a Pharo Block at a certain point of
> the execution or to make Pharo execute a Python’s lambda. I do not have
> answer for that.
>
>
You can do that in Pharo side or Python side , its up to you. Only you need
is a string that acts as a single. For example getValue: technically is
kinda like a callback because it sends the string containing the python
command but it waits for response from Python that will signal it if the
return string contains the signature, if I remember correctly, getvalue:
value. So essentially what I have done is create a mini transfer protocol.

It was necessary for me to do this not because of callback  per se, but
because I wanted to retain the live coding abilities of Pharo while coding
using Python libraries. In order to do that I wanted to send Python errors
back to Pharo and trigger the Pharo debugger with the python error as the
name of the error. To do that I had to implement a protocol that
diffirentiate between return values and value that concern only Atlas in
this case python errors.

This protocol can be extended of course to contain a myriad of things,
callbacks, thread synchronization, C function calls , C memory etc.

So technically speaking its already possible through Atlas. If you want to
do something very special with callback that involves the Pharo IDE as I
did with Python error you only need to extend this protocol adding your own
kind of signal strings.

>
> I think you could re-use the ideas behind the bridge but not the code. It
> is really specific to Python 3, I do not see how you could generate LISP
> using it as is.
>
> Julien
>

As far as my Atlas  is concerned I had made also a Python 2 version but
never bothered to continue developing it because I needed only Python 3.
The good news is Python 2 and 3 have minor differences when it comes to
sockets.

Indeed Atlas wont work magically with other language but porting it is not
hard because I tried to keep the majority of the code as much as I could in
Pharo side for this precise reason. So my initial intention was to provide
Atlas to Pharo community as a means to use libraries of any programming
language from inside Pharo. I hoped that people would use it as the
foundation to 

Re: [Pharo-users] A playground for Markdown?

[Dimitris Chloupis]

> I have argued time and again and in length about Markdown support in
> Pharo, so I will not do it again. I'll just repeat that, in order to make
> Pharo less isolated, Git support for managing software source code has the
> strategic importance, in the same way that Markdown support for managing
> documentation source code has strategic importance. This doesn't preclude
> support for native/alternative DVCS in the software front (Monticello,
> Fossil, etc) or markup languages in the documentation one (Pillar,
> Dokuwiki, t2tags, etc).
>

It's kinda funny because me and Esteban have been very early on huge
supporters of git and github when the rest of the community was mildly
interested to passionately against it.  I have been very vocal about it, to
the point of annoying people and being accused of just supporting a
overhyped product. 4 years later working with git is the official way of
doing things and we even have our very own github client in the image.

Pandoc has a feature set far, far longer and more important that Pillar and
> Markdown, including Yaml metadata blocks, fine grained exportation control,
> ePub and a myriad of other output (an input) formats support (see graphic
> below), a community that is mostly devoted to discuss extensively/mainly a
> lightweight markup language for "full stack" documentation, scholarly
> Markdown community for academic writing, annotated Markdown for
> collaborative editing and writing, programmable templates, multilingual
> scripting support, including embedded one for Lua (which came pretty handy
> to import our most recently publication[1][1a]). And that  just to mention
> some prominent features in the greater feature set that just Pillar or
> Markdown provides. As community we need to not blind ourselves to
> alternatives and overcome the Not Invented Here Syndrome, to see value in
> what is done outside Pharo for documentation in the same way we have done
> for software management (specifically Git).
>
> A playground for Markdown will enhance Pandoc integration, which we
> already have in Grafoscopio, but writing medium to long texts in it, using
> the current plain text input objects support is cumbersome. Despite that we
> have managed to have long book sized texts redone in Grafoscopio in an
> agile way. The Data Driven Journalism Handbook [2] has 300+ pages (13 Mb
> PDF) in a single Grafoscopio notebook, stored under just a 600kb STON file
> (and a 500 kb exported Markdown file).
>
> [1]
> http://mutabit.com/repos.fossil/dataweek/uv/Artefactos/BibliotecaDigitalBogota/pasos-para-bidibog.pdf
> [1a]
> http://mutabit.com/repos.fossil/dataweek/doc/tip/Artefactos/BibliotecaDigitalBogota/intro.md
> [2] http://mutabit.com/repos.fossil/mapeda/
>
> Several times, when I ask questions about Markdown, I'm pointed towards
> the Pillar existence, and I reiterate/expand my motives for wanting to
> implement *Markdown* support in Pharo. This exercise allow me to reiterate
> my questions in a more precise manner and hopefully this time someone will
> point me to a starting place about how to create a "playground for
> Markdown".
>
> Cheers,
>
> Offray
>

My personal opinion on this is that using syntax for documentation in 2017
feels to me like stone age. We did not even do this in 1980. I will dare to
predict and you can bookmark this post that Markdow will slowly disappear
to be replaced with the proper way of doing documentation and that is
through a dedicated documentation editor like Libreoffice.  Even Google
docs seem to return in favour of Markdown.

The wide range of documentation formats take only a tiny fraction of the
market. Adobe may have lost the war with Flash but when it comes to PDF
they have won and won it easily.

EPub for example is the least relevant format nowadays, it used be widely
popular format, nowhere near to pdf but popular indeed at the time of PDAs
but then iPhone came out and killed it together with Flash. Nowdays is used
mostly on Kindle which is also another device that has lost most of its
popularity.

I consider myself an expert on documentation because my day job is being a
lawyer and basically what we do is we write complex technical documentation
for courts. Especially my kind of lawyer that do not do criminal law. I am
writing legal documentation in a week what takes our community to write in
years.

Microsoft Office has been monopolising our field to an extreme extend and I
must be one of those rare exceptions that I use Libreoffice and quite
frankly I dont blame them because it has its issues.

No I am not a believer in Markdown which usage became relevant only because
Github supported it out of the box. With Github Markdown is nothing.

I am not a believer in LaText again, another specialised software that is
used by a very specific community.

I am not a believe in Pandoc, why bother with a million formats when only 2
dominate the market ?

I am not even a believer in doc string apis that exist for creating
reference 

Re: [Pharo-users] A playground for Markdown?

[Dimitris Chloupis]

For me Pillar has been the most underused feature of Pharo by far and it
makes me sad how little we take advantage of this great technology.

Pillar provides a feature set far longer and more important than markdown
but I think as a community we need to not only include Pillar inside our
standard distribution but built Pharo around it because it’s the perfect
nerve center that unites so many massively popular documentation
technologies like Markdown , LaTex, PDF and the usual suspect HTML.

The features are there. The only thing remaining is people using them.
On Fri, 29 Dec 2017 at 22:56, Offray Vladimir Luna Cárdenas <
offray.l...@mutabit.com> wrote:

> Hi,
>
> Playgrounds are a really good way to write short snippets of code and I
> wonder if such experience could be extended for larger pieces of
> Markdown. What I'm thinking of is have something similar but  like this:
>
> 1. Support for Markdown instead of Smalltalk, including syntax
> hightlighning and tab behavior (a tab equals two spaces).
>
> 2. Clicking on urls should load the respective web page. Clicking on
> images should  show an image preview.
>
> That's it, to start with. At some point it could be using GT Documenter
> previews, font support and so on. But I would like to start by extending
> the playground to just support this two features. Any advice about where
> can I start for the first feature?
>
> Thanks,
>
> Offray
>
>
>
>

Re: [Pharo-users] Learning Morphic

[Dimitris Chloupis]

You could look at my project ChronosManager, you can download from inside
Pharo and it’s main repo is here with a screenshot that demonstrates what
it is

https://github.com/kilon/ChronosManager

Reading it’s code should give the info you seek , there are comments as
well to help you

On Fri, 22 Dec 2017 at 22:41, T.D. Telford  wrote:

> I am primarily interested in graphical shapes and bit maps (for
> fractals).  I want to put graphical shapes or bitmaps in a window or
> bordered area. I have not been very successful in finding documentation
> about how to do this in Morphic.  In contrast, I find the documentation for
> Roassal easy to find and to the point.  Perhaps someone could point me to
> Morphic documentation (or supply examples) on my area of interest that
> includes a lot of examples. Thanks.
>
>

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[Dimitris Chloupis]

The beginner way
--
1. Open Pharo 6
2. Go to Welcome window
3. Go to Keymap Browser tab
4. Right click on a shortcut entry (for example global shortcut for close
window)
5. Choose Inspect Action
6. Go to Source Code tab
7. Profit

The Pharo coder way

Or go to SystemWindow class >> buildShortcutsOn:
or got to NautilusWindow class >> buildShortcutsOn: (any method will do)
or search for any method using the  pragma


On Sat, Dec 9, 2017 at 12:06 PM Prof. Andrew P. Black <bl...@cs.pdx.edu>
wrote:

>
> On 9 Dec 2017, at 07:44 , Dimitris Chloupis <kilon.al...@gmail.com> wrote:
>
> Making shortcuts in Pharo is no big deal, if 10% of people asking for
> Emacs or vim shortcuts bothered creating just 10 shortcuts each we would
> have by now at least 100 Emacs shortcuts in Pharo. When one say that needs
> something that He or she is not willing to do even 1% of its work, then he
> does not need it enough for others to bother.
>
>
> In September, I posted an Issue on pharo.fogbuz
> <https://pharo.fogbugz.com/f/cases/20466/Keyboard-Shortcuts>:  making
> keyboard shortcuts for the Pharo Smalltalk editor is not easy, but should
> be.   No one has responded to that issue saying that it really is easy, and
> explaining how to do it.  So if you know, I invite you to work on this
> issue.  tl;dr: I though that it was easy too, but after spending a couple
> of days trying to figure it out, gave up.
>
> If 10% of the energy expended in this thread had gone into fixing open
> issues, then Pharo would be getting better every day.
>

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[Dimitris Chloupis]

Nope , nothing to do with Emacs

GNU Smalltalk is Smalltalk without welll... Smalltalk
Which is why almost none is using it.

There is a project to use Pharo from inside Emacs called Shamoo. Frankly
you will be sacrificing a lot of IDE goodies leaving Pharo.

Neither Emacs or vim are proper IDEs , they are text editors pretending to
be IDEs and failing miserably at it.

On the other hand Pharo IS an IDE playing ball with big boys.

Making shortcuts in Pharo is no big deal, if 10% of people asking for Emacs
or vim shortcuts bothered creating just 10 shortcuts each we would have by
now at least 100 Emacs shortcuts in Pharo. When one say that needs
something that He or she is not willing to do even 1% of its work, then he
does not need it enough for others to bother.

It’s the difference between hype and actual desire.

On Fri, 8 Dec 2017 at 23:35, Kjell Godo  wrote:

> isn't GNU Smalltalk a emacs Smalltalk?
> maybe making a migration path from GNU to Pharo could be good?
>
> On Fri, Dec 8, 2017 at 1:33 PM, Kjell Godo  wrote:
>
>> if Pharo could have a emacs version or face or something
>> that would advertise more functions that you can get
>> from the Pharo version
>> or maybe link the two versions Pharo and emacsVimPharo
>> so there is like a migration path to Pharo
>> or they could work together
>> that could be lower the barrier to entry
>> i saw emacs vim guy who could also hate to learning something new
>>
>> On Fri, Dec 8, 2017 at 1:08 PM, Stephane Ducasse > > wrote:
>>
>>> Hi Richard
>>>
>>> Thanks this is nice. I like Greeter :)
>>> The suggestion of Ben are fun for the next one.
>>> I will add a link to your article.
>>>
>>> Stef
>>>
>>> On Thu, Dec 7, 2017 at 11:35 PM, horrido 
>>> wrote:
>>> > Done. Class #Hello is now #Greeter in package "HelloDemo".
>>> >
>>> > I presume we're good to go, then?
>>> >
>>> >
>>> >
>>> > Offray Vladimir Luna Cárdenas-2 wrote
>>> >> May be the class name could be changed a little bit to allow more
>>> >> flexibility using the Pharo Quick Start as a base. Something like
>>> >> "Greeter" and "Greeter new say: 'Hello world!'" or "Greeter new sayIt"
>>> >> could be implemented from there. Nice to see more and more
>>> documentation
>>> >> around Pharo, including this one.
>>> >>
>>> >> That being said, I have always felt that hello world is kind of a
>>> >> strange introduction to programming:
>>> >>
>>> >> http://mutabit.com/offray/blog/en/entry/dumb-hello-world
>>> >>
>>> >> Cheers,
>>> >>
>>> >> Offray
>>> >>
>>> >>
>>> >> On 07/12/17 15:31, horrido wrote:
>>> >>> I've revised the draft slightly for the comments given here:
>>> >>> https://medium.com/@richardeng/pharo-quick-start-5bab70944ce2
>>> >>>
>>> >>> Yes, it's a definite improvement. Thanks.
>>> >>>
>>> >>>
>>> >>>
>>> >>> Richard Sargent wrote
>>>  Excellent work, Richard!
>>> 
>>>  May I offer the small criticism against using #initialize for the
>>> method
>>>  name? I think a name like #sayIt (for example) and invocation like
>>>  "Hello
>>>  new sayIt" would make it explicit.
>>> 
>>>  This will be a great help for people who drop by out of curiosity.
>>> 
>>> 
>>>  On Thu, Dec 7, 2017 at 11:38 AM, horrido 
>>>  horrido.hobbies@
>>>   wrote:
>>> 
>>> > I've completed the first draft of my  Pharo Quick Start guide
>>> > 
>>> https://medium.com/@richardeng/pharo-quick-start-5bab70944ce2;
>>> > .
>>> > I
>>> > decided
>>> > to forge ahead anyway.
>>> >
>>> > Feedback welcome.
>>> >
>>> > Note that I chose wget instead of curl because many Linux distros
>>> do
>>> > not
>>> > have curl installed.
>>> >
>>> > I've tested the guide for various Linux distros including Mint 18.3
>>> > (Ubuntu-based), Debian 9.2.1, Manjaro 17.0.6 (Arch-based), Solus
>>> 3, and
>>> > Fedora 27. So it should be good for all the popular distros (Top
>>> 10).
>>> >
>>> >
>>> >
>>> > --
>>> > Sent from:
>>> http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>> >
>>> >
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>> >>>
>>> >>>
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>> >
>>>
>>>
>>
>

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[Dimitris Chloupis]

Now that’s what I call a great way to promote something. Excellent work,
short to the point.

In the future you could combine small code snippets together with the rest
of your arguments for explaining the awesomeness of Pharo. Apple does this
very well and in similar style to what you have done here.

I love the size , quick to read, easy to understand.


On Fri, 8 Dec 2017 at 16:42, horrido  wrote:

> I'm not sure what you mean by *PrintIt:*. If you mean type 'Hello World' in
> the Playground and just *Print it*, that's not really a "program."
>
>
>
> Sean P. DeNigris wrote
> > hernanmd wrote
> >> To me the Hello World in Smalltalk was always just writing: 'Hello
> world'
> >
> > +1. While putting it in a class shows a few more of the system's
> features,
> > it also makes it seem more complex than other languages, when that's not
> > really true. Why not just PrintIt: 'Hello world'? If it seems important
> to
> > show classes, maybe start with PrintIt: 'Hello world' and step-by-step
> > build
> > through `Transcript show: 'Hello world'` to the class-based solution.
> >
> >
> >
> > -
> > Cheers,
> > Sean
> > --
> > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

Re: [Pharo-users] I love the launcher!!!!

[Dimitris Chloupis]

Unless we talk about a diffident launcher I am not aware of. Pharo launcher
is both a GUI last time I checked and loadable inside any image. So
technically speaking you don’t need neither the GUI nor the command line.
You can fully integrate it and automate it with your own project and then
publish that project to Package Browser so that downloads and installs from
inside the image with a single click. It’s just regular Pharo code like
anything else.

On Wed, 29 Nov 2017 at 12:41, Prof. Andrew P. Black 
wrote:

>
> On 23 Nov 2017, at 12:56 , Herby Vojčík  wrote:
>
> Pardon my question, I have downloaded it and looked at it, but I don't get
> it. What does it do / what are the use cases (honest question)?
>
>
> I also was completely confused by what the launcher was for.  And when I
> tried it, it did not seem to load.  Now that I know what it is for, it is
> very useful.  So I will try to explain the basics.
>
> The launcher is *not* a project that you load into your Pharo image.  It
> is stand-alone command line tool that you use for creating and managing
> your images.  It lets you quickly and easily:
>
>
>- download the latest pre-built Pharo image and create your own copy.
>   - you can choose from Pharo 6.1 stable or Pharo 7 development
>   - You can choose 64 or 32 bit
>- manage multiple images on your computer
>   - Launch (with the right VM), with and without your personal
>   settings,
>   - Delete old images
>- run multiple images in parallel
>
>
> The “Save as ...” command in Pharo is unfortunately *not *at this time
> compatible with the launcher, so if you create a new image using Save As
> ..., it will not show up in the launcher.
>
> You should be able to launch the launcher by double-clicking on it from
> your OS.  In MacOS, I have it in the dock.
>
> Perhaps someone can put some text like what I have written above on the
> web page?  We often assume that people know ... well, they mostly don’t!
>
> Andrew
>
>
>
>

Re: [Pharo-users] How do you store and manage small programs?

[Dimitris Chloupis]

I use github and Package Browser, Package Browser is for intalling packages
from inside image. For small code snippets I use Gist which supports
Smalltalk syntax.
For example
https://gist.github.com/kilon/ef8a99d94637eadfac339107e1ace233

On Sat, Nov 25, 2017 at 7:35 PM Andy Burnett <
andy.burn...@knowinnovation.com> wrote:

> I have just created a couple of small playground scripts that do some
> useful data wrangling. The chances are that I will reuse them from time to
> time, but with tweaks. Does version 6 Have some way to store them? I think
> I am after a sort of scripts catalogue.
>

Re: [Pharo-users] Short report about Pharo experience

[Dimitris Chloupis]

Hans, feedback is probably one of the most crucial elements in improving
software. So not only classifies as help in my book its up there on top.

Improvement for the shake of improvement is just pointless. Feedback helps
show a common path that can keep users as happy as possible.

Also note that we all express our own opinions here, none represents Pharo.
At no point should you keep quite and not participate in the discussion. We
are humans, not robots. Disagreement is part of the game and frankly this
community in my 5 years being around has been more than welcomed to me and
many others. I know because I tend to ask many stupid questions :D

Plus the points you already discussed have already mentioned by many other
people, so clearly there is a desire for improvement there.

What Stef probably means is that he agrees with you and that the problem is
not disagreement but rather that we do lack contributors to push those
things forward. Which frankly I do not blame him, because he already has
lifted by himself the vast majority of the documentation of Pharo. I used
to be far more active, but alas I cannot be as active contributor to
documentation as I used to.

You are correct, there are glaring issues with Pharo, especially the way we
expose the amazing set of features that Pharo has for customisability but
then Stef is correct as well  in that in the end it comes down to who is
willing to contribute. That does not mean we do not appreciate feedback,
its definitely very important. Code and documentation contribution is more
important though.

On Thu, Nov 23, 2017 at 12:54 PM Hans 
wrote:

> Hi Stef,
>
> my post is intended as feedback. Action is a different thing. Feedback may
> help to indentify useful actions. In this sense, I thought feed back is
> help, too. May be I'm wrong.
>
> If you thing feed back is useless and without value, and only "action"
> counts, then is this your opinion. Then I'll take my actions (which are
> there, I develop on TeaPot, as you could read) and be quiet. Full Stop.
>
> Hans
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

Re: [Pharo-users] Short report about Pharo experience

[Dimitris Chloupis]

Me ?

I don’t follow you, I am a member of this community since 2011 with active
contributions to documentation, tutorials , promotion and improvement of
Pharo.

Much less now days because I am busy but still around offering advice and
answers in mailing list and managing the Discord server. Does not that
count as action ?

On Thu, 23 Nov 2017 at 12:16, Stephane Ducasse <stepharo.s...@gmail.com>
wrote:

> My question is then the following:
> How do you help?
> There is no little action. Any action is an action.
> And all together we get stronger. Do not expect everything from us.
> Join and have fun.
>
> Stef
>
> On Thu, Nov 23, 2017 at 11:01 AM, Dimitris Chloupis
> <kilon.al...@gmail.com> wrote:
> > Just to clarify, you will never read from me that Python or Pharo is
> > superior or what else.
> >
> > Superior and better is highly subjective and depends obviously on your
> needs
> > and specific problem you want to solve.
> >
> > What I am saying , is yes I am perfectly ok and even encourage Pharo
> > offering similar functionality we come to expect from other IDEs,
> languages,
> > third party tools etc . There is definetly a lot of value in offering
> > something that is easier to learn and an easier way of doing things. The
> > essense of computers is to automate stuff. But like any other language,
> IDE,
> > third party tool etc Pharo attracts a specific kind of people.
> >
> > Python attracts people that want the easiest learning curve possible
> > C attracts people who want the highest performance code possible
> > Pharo attracts people who want a highest productivity workflow with full
> > customisability.
> >
> > Which one is best ? Hmm highly debatable, which is why language wars
> end
> > to up nowhere.
> >
> > Its not that Pharo cannot be fast, or easy to learn, its not that C
> cannot
> > be easy to learn and fully customisable and highly productive and its not
> > that Python cannot be top performance or highly productive and full
> > customisable. But each one has its own priorities and life is all about
> > priorities.
> >
> > On the matter of application deployment to offer you some recommendations
> >
> > What you can do
> > 1) Rename the executable, which basically contains the VM
> > 2) Change the icon of the executable
> > 3) Create a startup script , if you want to have some kind of default
> > behavior when the user first opens Pharo or each time it opens it
> > 4) Use attached morphs to world, these morphs cannot be resized, take the
> > entire space of pharo window and block any interaction with the Pharo
> ide.
> > When you dont not want your user to access your application internals.
> > 5) Morphic offers themes you can use to add a special touch to your
> > interface even making it look more native
> > 6) There is no need for an installer but if you want to create one
> because
> > of dependencies that are shared among application you can use any third
> > party tool that can be used for any other language , nothing special here
> > 7) You can offer automatic updates via git, Metacello gives a  lot of
> access
> > to git functionality so you can connect to your git repo , check the
> latest
> > version and redowload the source in the background using a fork process
> > 8) you can use makefiles with Pharo for generating diffirent builds for
> your
> > application, again you can use pharo startup scripts to automatically
> > install code to a freshly build image.
> > 9) The help tool can be used as internal documentation of your image
> > 10) If you want a cheap way to crate a multi core application, you can
> > trigger multiple instances of pharo and let them talk with each other via
> > sockets. Each istance will be assigned by OS to a separate core
> > 11) If you must absolutely have a native interface run pharo without its
> ui
> > (this happens with the use of pharo.exe instead of pharo-ui.exe ) and use
> > the UFFI to generate your interface using the the native interface of
> your
> > OS. This of course will make your application non cross platform but is
> > still a popular choice for mosr desktop applications
> > 12) Its also possible use HTML/JS as GUI for Pharo, again you can use a
> web
> > engine, like WebKit and UFFI
> > 13) Ask questions here for anything, never hesitate
> > 14) If all fails you can always use Pharo together with other languages,
> > again using sockets, or shared memory, or pipes, Pharo gives you full
> access
> > to your OS and the OS offer many ways for communication between process /
>

Re: [Pharo-users] Short report about Pharo experience

[Dimitris Chloupis]

Just to clarify, you will never read from me that Python or Pharo is
superior or what else.

Superior and better is highly subjective and depends obviously on your
needs and specific problem you want to solve.

What I am saying , is yes I am perfectly ok and even encourage Pharo
offering similar functionality we come to expect from other IDEs,
languages, third party tools etc . There is definetly a lot of value in
offering something that is easier to learn and an easier way of doing
things. The essense of computers is to automate stuff. But like any other
language, IDE, third party tool etc Pharo attracts a specific kind of
people.

Python attracts people that want the easiest learning curve possible
C attracts people who want the highest performance code possible
Pharo attracts people who want a highest productivity workflow with full
customisability.

Which one is best ? Hmm highly debatable, which is why language wars
end to up nowhere.

Its not that Pharo cannot be fast, or easy to learn, its not that C cannot
be easy to learn and fully customisable and highly productive and its not
that Python cannot be top performance or highly productive and full
customisable. But each one has its own priorities and life is all about
priorities.

On the matter of application deployment to offer you some recommendations

What you can do
1) Rename the executable, which basically contains the VM
2) Change the icon of the executable
3) Create a startup script , if you want to have some kind of default
behavior when the user first opens Pharo or each time it opens it
4) Use attached morphs to world, these morphs cannot be resized, take the
entire space of pharo window and block any interaction with the Pharo ide.
When you dont not want your user to access your application internals.
5) Morphic offers themes you can use to add a special touch to your
interface even making it look more native
6) There is no need for an installer but if you want to create one because
of dependencies that are shared among application you can use any third
party tool that can be used for any other language , nothing special here
7) You can offer automatic updates via git, Metacello gives a  lot of
access to git functionality so you can connect to your git repo , check the
latest version and redowload the source in the background using a fork
process
8) you can use makefiles with Pharo for generating diffirent builds for
your application, again you can use pharo startup scripts to automatically
install code to a freshly build image.
9) The help tool can be used as internal documentation of your image
10) If you want a cheap way to crate a multi core application, you can
trigger multiple instances of pharo and let them talk with each other via
sockets. Each istance will be assigned by OS to a separate core
11) If you must absolutely have a native interface run pharo without its ui
(this happens with the use of pharo.exe instead of pharo-ui.exe ) and use
the UFFI to generate your interface using the the native interface of your
OS. This of course will make your application non cross platform but is
still a popular choice for mosr desktop applications
12) Its also possible use HTML/JS as GUI for Pharo, again you can use a web
engine, like WebKit and UFFI
13) Ask questions here for anything, never hesitate
14) If all fails you can always use Pharo together with other languages,
again using sockets, or shared memory, or pipes, Pharo gives you full
access to your OS and the OS offer many ways for communication between
process / applications / executables.



On Thu, Nov 23, 2017 at 11:09 AM Hans N Beck <
hnb...@educational-concepts.biz> wrote:

> Hi Stef,
>
> sure :)
>
> But just before let me comment the other posts: yes you’re right. Pharo
> and Smalltalk follows a different philosophy and therefore some common
> terms like „app“ and „ide“ doesn’t make sense or have to be reinterpreted.
>
> You can always say: look, I have a super cool concept, dive In but you
> have to forget every thing else.
> OR:
>  I offer you  a new concept,  look how it can help you to solve daily
> tasks and getting jobs done.
>
> Both perspectives have value to me. And I don’t say Pharo should priories
> the one or other. But with my post, I’m taking the perspective of I need a
> tool to solve problems, in my given environment, my colleagues, my
> customers, my IT infrastructure, my constraints.
>
> Pharo is well in being the superior new concept. We know that. All what I
> want give you, the Pharo experts the feedback that I’m very happy them that
> Pharo is on the way for having value for the other perspective, a tool for
> solving problems in daily work.
>
> Not more not less.
>
> Cheers
>
> Hans
>
>
> > Am 23.11.2017 um 09:54 schrieb Stephane Ducasse  >:
> >
> > Hi hans
> >
> > Thank you for this analysis.
> > Now do you want me to state a question?
> >
> > Stef
> >
> > On Thu, Nov 23, 2017 at 12:23 AM, Hans N Beck
> > 

Re: [Pharo-users] Short report about Pharo experience

[Dimitris Chloupis]

>
> - Deployment: it should be possible to deploy a „single click“
> application, independet if native GUI or Web App or Shiny like
> - More standard solutions: many libraries have examples, but they are
> sometimes to trivial or just irrelevant for daily practice
> - More product oriented: libraries should have more wizzards or
> application pattern. Imaginary example: for Teapot or Seaside would it be
> fine if there were some code generator for a 4 Tile dashboard app, or a
> data viz app, themes like in hugo or bootstrap. I may be wrong, but the
> nature of many libraries or tools is „make anything possible“ instread of
> „I help you to write your product“. Do you understand what I want to say ?
>
> Anyway. I can state: Phare IS on the right way. It is. Much much progress
> the last years. Thank you all ! And if it becomes more and more a product
> for professionals (in industry), the future will be top ! And this doesnet
> mean to give up the computer science part. Pharo is cool to try concepts
> and ideas. So Pharo has BOTH sides, which does it make great.
>
> Cheers
>
> Hans
>

 if by single click you mean you press a button and an application is
created , technically with pharo you dont even need to push a button, as
pharo is already an application.

Pharo is not an IDE, is not a language, is not a virtual os , or a live
coding enviroment. Its simply an application that fullfils all these
roles.You may say "so what, everything is an application" , well not quite
because Pharo is an application practically written in itself offering you
direct access to all its internal making it completely customisable. Even
its VM can be customised from inside Pharo which if you think about it,
other languages would consider this a form of insanity and to a point they
are correct to do so.

Thus there is no point of creating standalone applications with Pharo
because this goes against its very ideology of IDE, most IDEs nowdays miss
the I, standing for Integration which means that you integrate development
tools, plus language plus your code in one thing. These things are not used
merely to create the application they are meant to be included with the
application you create. I usually say to people that they have no clue what
integration means until they coded in Smalltalk. Smalltalk is just light
years ahead in that departmen and so is Pharo.

A standalone application rips these things apart , its the seperation
between development builds and release builds that are far less meaningful
for Pharo and you will rarely read about them in this mailing list.

The actual problem of Pharo is the sever lack of documentation. Its much
better nowdays than it used to but the fact remains that biggest weakness
of Pharo is that it moves about 1000 times faster than its documentation.
This is one huge disadvantage of a very productive/ succesful development
enviroment.

Python which is a language I also regularly use on daily basise, its a
language that barely changes wtih each version. The only singificant change
for Python was Python 3 and even that pales in comparison to the massive
changes we see in each Pharo version. The next version of Pharo for example
may have a completely new GUI API , that is something you rarely see
happening to a language. This is ok because Pharo obviously is not a
programming language and neither is Smalltalk.

On the matter of standalone applications , Pharo offers a masive degree of
customisation that is unknown even amongst its most experienced users.
Pretty much anything you see and dont see is customisable. So ironically
Pharo offers a much larger degree of efficiency for generating standalone
applications than any IDE or language out there , or even third party tool.
By standalone in this case I mean application that execute by themselves
without even a need to be installed.

The reason for this, is the same reason Pharo is so extremely productive.
Its not the live enviroment, its not the pure OOP, its not the IDE, or the
simplicity of the language.

Its the I, Integration.

No language or IDE , however much more powerful it may seem can ever come
close to competing with Pharo. That does not make Pharo the best choice,
just the most flexible.

In the end the fact that Pharo evolution is thousands times faster  than
its documentaiton is a very solid reason not to use Pharo and not to
recommend to others. Because in the end documentation is extremely
important.

But this is one of those scenarios of not having your cake and eating too.
With Pharo you choose to sacrifice documentation for high coding
productivity. Of course lack of documentation hinders productivity but that
is only temporarily until you learn what you want to learn.  But then
learning what you want make take years if not decades.

To explain how one can create a standalone application with Pharo in full
detail is to explain the entire Pharo in full detail. This is why articles
that have been written in the past just barely 

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo TechTalk 21 Nov: Discord Demo

[Dimitris Chloupis]

Well done :)

Now you can make a discord client inside the Pharo image if you want.
On Tue, 21 Nov 2017 at 21:03, Juraj Kubelka 
wrote:

> Hi,
>
> the TechTalk record is available at the same link:
> https://www.youtube.com/watch?v=33kXsOiP6wA
> and includes outline to simplify navigation.
>
> Cheers,
> Juraj
>
>
> TechTalk Outline:
> - 01:58 The beginning of the talk
> - 04:30 Webhook
>   - 04:33 How to Create Webhook
>   - 05:39 Webhook Examples
>   - 10:33 Webhook Use Case: Script of the Day from Nautilus Code Browser
>   - 18:39 Webhook Use Case: Server Problem Notification
> - 22:45 Bot App (chatbot)
>   - 24:47 How to Create a Bot App
>   - 28:28 Bot App Examples
>   - 33:17 Bot Use Case: Source Code Expertise
> - 41:40 Standard User Client
>   - 42:57 User Client Example
>   - 45:06 User Client Use Case: Asking Directly from Pharo Playground
>   - 47:06 User Client Use Case: Receiving Questions and Answering in Pharo
>   - 50:50 Final Thoughts About Discord Integration in Inspector and
> Debugger
> - 52:44 Discussion
>
> On Nov 21, 2017, at 12:54, Juraj Kubelka  wrote:
>
> Hi!
>
> The TechTalk starts in about 10 minutes. Join us on Discord, the techtalk
> channel.
>
> Cheers,
> Juraj
>
>
> On Nov 21, 2017, at 10:11, Marcus Denker  wrote:
>
> The link to the live stream is this:
>
>  https://www.youtube.com/watch?v=33kXsOiP6wA
>
> It start in a bit less than 3 hours.
>
> Marcus
>
> On 18 Nov 2017, at 09:13, Marcus Denker  wrote:
>
> Pharo TechTalk: Discord Demo
> When?  21 Nov 2017 5:00 PM - 7:00 PM (UTC+01:00)
>
> Topic: "Discord communication Demo”, how to script discord from Pharo.
>
> https://association.pharo.org/event-2642665
>
>
>
>
>

Re: [Pharo-users] New Pharo article at The Cohort

[Dimitris Chloupis]

>
>
> First of all, you need to understand that this article, like nearly all of
> my other articles, is about /marketing/. I've never made any bones about
> this.
>
> If you know anything about marketing, you know that it involves
> exaggeration
> and hyperbole. It sometimes involves bending the truth. The point of
> marketing is to persuade on an emotional level, not a logical one.
>
> This is exactly what companies like Apple and Microsoft do. If you think
> Apple ads tell the absolute truth, then you are terribly naive.
>
> So, is Pharo being used to fight Ebola? Not exactly, but who cares? I'm
> trying to change people's perception. I'm trying to *move* them. If I have
> to exaggerate, I will do so.
>

Actually there is a guy that I know that he actually cares

very much

he is called

"Mr Law"

When a marketing , bends the truth and especially when it lies under UK,
Greek  and European Law is called "fraud" and it punishable under
crimininal (jail time) and civil (compensation for damaged cause by
fraudalent marketing) law. The penalties can be extemely severe if the
fraud caused a substantial amount of damage in some way.

Under those legal systems I have studied (I am a lawyer) the only case that
someone is allowed to lie is when he defiends himself. If you ever wondered
how its possible lawyers to lie , now you know. Lying and bending the truth
in this case is a legal principe set since ancient times by law to provide
extra pressure to prove the a party is guilty. Its called "proof beyond
reasonable doubt" and is  a very important legal principle.

Outside that, say I submited a document as a defense lawyer that is edited
or changed in some way , its fraud and especially fraud against the court
is even more punished. If a witeness , exaggerates , bends the truth and
especially if he or she lies, its fraud and the court can send him straigh
to jail with his lawyer.

Apple certainly does not do what you.

Actually Apple goes to great lenghts proving its claims , usually when
Apple says "iPhone has a battery of 10 hours" you will see an asterisk that
will point you to small letters in the bottom of the page that says exactly
under which conditions 10 hours can be achieved.

On the other hand its use of words like "magical" is not of objective value
and by no means can misled or tell a lie because well, magic does not
exist. The law assumes the a person has at least average intelligence and
knowledge (exceptions of course people with mental disablities).  Most of
the words that Apple uses in the ads that could be considered lies or bend
truth are purely subjective terms.

https://www.apple.com/iphone/

"Your face is now your password. Face ID is a secure and private new way to
unlock, authenticate, and pay."

Say some experts come forward and prove that Apple's technology is not safe
and especially if they prove that Apple knew it was not safe when it
launched it, Apple is liable under law for fraud.

There is of course a lot of illegal marketing out there, fraud after all is
according to my experience the most common offenses that I have came
accross in my 10 years carrier as a lawyer , but I can assure you just it
may happen quite often does not make it any less illegal. You going to be
shocked how many illegal things happens on the internet and the law's
complexity and sophistication in providing protection against those things.

Of course I am not saying that someone is going to bother sue you tommorow,
as its highly unlikely that someone will take your posts seriously as they
are dominated by exaggerations and I have told you so many times in the
past. But that does not mean he cannot.

Maybe USA law is more relaxed, because it not the most respected legal
system, as USA has a notorious bad record with human right and consumer
protection. But none the less I can promise you in Europe, what you do is
not legal and there are special legislation to protect consumers for these
scenarios.

Re: [Pharo-users] Smalltalk Argument

[Dimitris Chloupis]

all people like popular choices, including engineers.

Engineers may be more careful but they are not known exactly for their
talent to innovate.

We are pact animals, we are social animals.

This is far from a coding problem, its pretty much coded right inside our
DNA, not just for us but also for any other animal.

And we have our trends too, our resistance to git is an excellent example.
A general fixation of avoiding files and especially text files. The
unreasonable argument that you need an image to preserve a live coding
enviroment. The idea that just because you have access to the complete
source code , life becomes easier for some weird way as if people are
likely to mess with the internals of a system. That for some weird reason
you cannot have access to source code in other languages or that is hard to
do so. The notion that live coding is only possible or only easy in
Smalltalk. That reimplementing everything in Smalltalk is a great idea.
That minimal syntax equals softer learning curve. That Smalltalk is the
only sensible way of doing OOP.

Finally but not least, "Alan Kay is god".

People love to stick to their beliefs (me included) and not feel
comfortable questioning them. It's no surpise it tooks us hundrends of
thousands of years to get to this point.

JS is chosen as a language for the same reason its so hated, its third
party libraries. As coders we have to rely a lot more to libraries than we
have to rely on languages. Sure a language can solve many potential problem
but a powerful library support can practically give you code on a plate.
Hence also why JS is practically non existant outside web dev and that is
pretty rare for a language.

So sure popularity plays a major role but in the end the preference for JS
is not insanity, its the right choice for what it focuses on. A difficult/
not that well designed language + big library support will always be easier
to use than a super ease elegant language without such big library support.
The time when we were relying on our code and our own libraries has passed
long time ago.



On Mon, Nov 6, 2017 at 10:37 AM Andrew Glynn <aglyn...@gmail.com> wrote:

> Btw, I think we gained *pace* when JS took over the front end, but lost
> visibility.  Nothing is slower than coding a client/server app with the
> front end in JS. The ‘rise’ of JS is a side effect of the fact that the web
> was designed, built and continues to be built by ‘coders’ who don’t know
> enough to be called amateurs.
>
>
>
> What puts 'coders’ off though is related to way JS is and (mostly doesn’t)
> work.  You can’t just sit down and ‘hack on’ Smalltalk until it ‘sorta
> kinda’ does what you want.  You can’t grab code from some random website
> and ‘fiddle with it’ until it ‘sorta kinda’ works. ‘Coders’ *can’t* make
> it ‘sorta kinda’ work, and they don’t know how to *write* code that works.
>
>
>
> One of the better JS programmers I’ve worked with said at one point
> “Engineers can’t write JavaScript because it doesn’t fit their mentality.
> I used to be a retoucher, I’d spend hours and hours getting one pixel
> right.  There’s no good reason that one pixel had to be that way, but the
> image didn’t ‘go’ otherwise. JavaScript is like that, you spend hours and
> hours messing with it, getting it to work, and at the end you don’t know
> why it works, nor why it didn’t.  That’s not an engineer’s mindset.”
>
>
>
> Do aviation engineers choose tools based on ‘popularity’? At the same
> time, would you want your next flight to be on an aircraft running on
> JavaScript?  I wouldn’t eat from a microwave running JavaScript.
>
>
>
> I’d rather be an engineer than a popularity contestant or a fashion victim.
>
>
>
> In any case, more often than not it’s management that chooses
> technologies, generally based on who they have lunch with more than
> anything else.
>
>
>
> Andrew
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Dimitris Chloupis <kilon.al...@gmail.com>
> *Sent: *Monday, November 6, 2017 2:35 AM
>
>
> *To: *Any question about pharo is welcome <pharo-users@lists.pharo.org>
> *Subject: *Re: [Pharo-users] Smalltalk Argument
>
>
>
> Another way of promoting Pharo is copying its advantages to other
> languages. The ideal way is for people to get straight to Pharo and fall in
> love with it. But sometimes this may be possible for several reasons. The
> most usual being that people simple are not in the mood of learning a new
> language unless they have to. As the saying goes "People love progress ,
> its just that they equally hate change"
>
>
>
> Introducing similar features to another language, like I did with
> introducing live coding enviroment to Python with direct r

Re: [Pharo-users] Smalltalk Argument

[Dimitris Chloupis]

Another way of promoting Pharo is copying its advantages to other
languages. The ideal way is for people to get straight to Pharo and fall in
love with it. But sometimes this may be possible for several reasons. The
most usual being that people simple are not in the mood of learning a new
language unless they have to. As the saying goes "People love progress ,
its just that they equally hate change"

Introducing similar features to another language, like I did with
introducing live coding enviroment to Python with direct reference back to
Pharo is a very good way to promote the language. Just because you cannot
code in Pharo at your work does not mean you cannot code the Pharo way.
Just put a huge tag in your documentation, comments and anywhere you
mention your code "inspired by Pharo ( https://pharo.org)" and you will get
their attention whether they like the idea of learning a new language or
not.

Its like watching an ad, using sex, humour and even unrelated stuff to grab
your attention to a product. The idea here is to get the attention, once
you do that, the rest follows.

A huge problem with Smalltalk in general is that even though every
language, enviroment, tool, IDE has been copying it , it is rarely
mentioned. If it did , I have no doubt it would have been masively more
popular than it is right now.

On Mon, Nov 6, 2017 at 9:22 AM jtuc...@objektfabrik.de <
jtuc...@objektfabrik.de> wrote:

>
> Phil,
>
> Am 26.10.17 um 08:17 schrieb p...@highoctane.be:
> >
> >
> > Now we miss the boat on mobile and bigdata, but this is solvable.
>
> You know, "It's solvable, and it's even easy in Smalltalk" has been what
> we've been shouting down at those worms in the C++/Java swamp for
> decades. We just never really proved it. We also missed the boat on web.
> Seaside was the last real innovation in that field, almost 15 years ago.
> When Javascript took over the frontend, we lost pace.
>
> >
> > If we had an open Java bridge (and some people in the community have
> > it for Pharo but do not open source it - so this is eminently doable)
> > + Pharo as an embeddable piece (e.g. like Tcl and Lua) and not a big
> > executable we would have a way to embed Pharo in a lot of places (e.g.
> > in the Hadoop ecosystem where fast starting VMs and small footprint
> > would make the cluster capacity x2 or x3 vs uberjars all over the
> > place)  this would be a real disruption.
>
> To it sounds like a big ball of mud to me, but that is opinion ;-)
>
> >
> > Think about being able to call Pharo from JNA
> > https://github.com/java-native-access/jna the same way we use C with
> UFFI.
> >
> > Smalltalk argument for me is that it makes development bearable (even
> > fun and enjoyable would I say) vs the other stacks. That matters.
> >
> Yep. As long as there is no mobile, web or big data involved ;-) To me
> that is not enough for convincing project managers these days, because
> web, mobile and big data as well ass AI (oh, is that probably no. 4 on
> our list of missed boats?) are the topics of what we consider
> future-proof projects... I am not only dissing the Pharo community here,
> this is a problem for all Smalltalk vendors in my opinion.
>
>
> Joachim
>
>
>
> --
> ---
> Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
> Fliederweg 1 http://www.objektfabrik.de
> D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com
> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
>
>
>

Re: [Pharo-users] UFFI and Fortran

[Dimitris Chloupis]

Yes Atlas , a library I made that is available via Package Browser from
inside the Pharo image, makes Pharo capable of using any cpython library
from inside Pharo, with Pharo syntax, live coding and debugging again
inside Pharo. The Pharo syntax is limited to just calling methods and
variable assignments. The library also has inlining python code (pass path
code as a string from inside your pharo code) that gives access to full
python capabilities (creating Python classes, list comprehensions,
decorators, threading, multiprocessing etc).

The advantage of using UFFI over Atlas is that it gives far better
performance. Plus gives access to C libraries not wrapped for Python.

The advantage of Atlas is that allows for dynamic execution of the library
without the need for the creation of wrappers.  Plus it allows for remote
execution, meaning the python library can be in another computer or server
anywhere in the world. So its much more than a FFI.

Of course both approaches will require from you to map C or Python data to
Pharo objects.

At some point I will update Atlas to be as fast as UFFI , adding to the
socket functionality also shared memory that is vastly faster. For now this
is a low priority for me.

On Fri, Nov 3, 2017 at 5:10 AM horrido  wrote:

> Sounds like it's possible to call into TensorFlow (Python) from Pharo. That
> would give Pharo a tremendous boost for machine learning applications.
>
> Am I right?
>
>
> kilon.alios wrote
> > Maybe you talk about TalkFFI which aumatically wrapped C libraries for
> > Pharo and i think Squeak as well but used Nativeboos, i think
> >
> >
> http://forum.world.st/TalkFFI-automatic-FFI-generation-for-Pharo-td4662239.html
> >
> > On the subject of Fortran yes you can use UFFI if Fortran code is
> compiled
> > as a DLL (or equivelant non Windoom OSes)
> >
> > https://software.intel.com/en-us/node/535305
> >
> > Dynamic Library format are not exclusive to C for generation , many
> > languages can generate them so even though UFFI is used predominatly for
> C
> > any language that can generate a DLL without any name mangling should be
> > accessible via UFFI.
> >
> > if DLL generation is not possible, then you can drop down to my solution
> > of
> > Shared Memory Mapped Files. Which means you make an executable in Frotran
> > (or any other language)  that contains the code you want to access and
> > creates a shared memory region and you can access that region from Pharo
> > via UFFI.
> >
> > This is how I built my CPPBridge project. Which one can use as a template
> > for generating similar bridge for Fortran or any other language where the
> > generation of DLLs is not practical or possible.
> >
> > The shared memory region can be used also as a means of communication
> > additional to sharing live state, memory mapped files automatically save
> > the live state so next time you open the file it behaves as you would
> > expect a Pharo image to behave by restoring the live state. A means to
> > extend Pharo image to include memory not managed by the VM.
> >
> > Because memory mapped files is mechanism of the OS Kernel and is also the
> > mechanism used for the loading of dynamic libraries like DLLs there is
> > also
> > no loss of performance and is the fastest way of communication between
> > languages, libraries and applications.
> >
> > So yes using Fortran code is possible via UFFI in more than one way.
> >
> > But in the end it should be noted here that because IPC mechanisms
> (common
> > way of using libraries from other languages) are based on core OS
> > functionality like , memory managment, sockets , pipes, etc its not hard
> > to
> > use libraries from any language from inside any language.
> >
> > So Pharo can use Fortran libraries and Fortran can use Pharo libraries,
> > its
> > also possible to retain live coding even when executing code written in
> > another language through various means. Recently I was succesful in
> making
> > Python into a basic live coding enviroment , meaning code that when
> > changed
> > in the source file it updates also existing live intances as you expect
> in
> > Pharo. Python also supports memory mapped files so its possible to create
> > a
> > joined live coding enviroment and live image that containes both Pharo
> and
> > Python bytecode. Of course without touching VM source code.
> >
> > Even though live state is not tricky to retain for compiled languages,
> > live
> > code can be a bit trickier to do but still not impossible or that hard as
> > most would assume.
> >
> > Sky is the limit.
> >
> > Bottom line is that if you have a favorite library in any language you
> can
> > use it from inside Pharo with at worst a few hundrend lines of setup code
> > you can create as a library and of coure reuse next time you want to use
> > again a library from another language without having to write a line of
> > additional code. The technology is available is just a matter of learning
> > how 

Re: [Pharo-users] Pharo: Reinventing Smalltalk

[Dimitris Chloupis]

Should pretty standard even for Java using a debugger

I mean I have done this with Visual Studio and its debugger with C++. It
even allows you to inspect the machine code or see the memory in raw bits
formats. So I find it hard to believe that Eclipse cannot do that with Java.

There is even a feature which is called watching a variable that pops the
debugger only when a specific variable changes value. The functionality is
there , the terminology is different.

On Thu, 2 Nov 2017 at 01:12, henry <he...@callistohouse.club> wrote:

> I am only familiar with Eclipse, not other Java development environments.
> In comparison, what is lacking in the land of Java, which is so powerful in
> Pharo/Squeak/Smalltalk is the ability to inspect the object resulting from
> some highlighted code. As a developer, Smalltalk wins on inspectability.
>
> - HH
>
>
> On Wed, Nov 1, 2017 at 17:47, Dimitris Chloupis <kilon.al...@gmail.com>
> wrote:
>
> Well I rather not reply because I am a huge hater of multi window GUIs .
> Thank god Pharo is not.
>
> Seriously how on earth someone can find convenient multiple windows is
> beyond my understanding . It was a terrible idea in 90s , it’s still a
> terrible idea.
> On Wed, 1 Nov 2017 at 23:05, horrido <horrido.hobb...@gmail.com> wrote:
>
>> FYI, reader comments to my interview with Stef:
>>
>> https://www.reddit.com/r/programming/comments/7a30vx/pharo_reinventing_smalltalk/
>>
>> If you can respond, that would be great.
>>
>>
>>
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>
>>

Re: [Pharo-users] LiteratureResearcher - where graphs, PDFs, and BibTex happily live together

[Dimitris Chloupis]

Super cool more detailed recommendations when I try it on practice

A cheap pdf viewer in Pharo would be to turn pdf pages to JPG images which
you can load via image morph so you won’t have to have two separate
windows. There are ton of converters out there that can do this.
On Wed, 1 Nov 2017 at 23:17, Manuel Leuenberger 
wrote:

> Hi everyone,
>
> I was experimenting in the last few weeks with my take on literature
> research. For me, the corpus of scientific papers form an interconnected
> graph, not those plain lists and tables we keep in our bibliographies. So,
> here is the first prototype that has Google Scholar integration for search,
> can fetch PDFs from IEEE and ACM, extracts metadata from PDFs - all this
> results in hyperlinked PDFs!
>
> See a demo here: https://youtu.be/EcK3Pt_WnEw
> Also slides from the SCG seminar here:
> http://scg.unibe.ch/download/softwarecomposition/2017-10-31-Leuenberger-ILE.pdf
>
> I plan on packaging it, so that those who are interested can check it out
> themselves (help wanted!). Currently, it only works on macOS.
>
> What do you think of my approach? Which use cases should be added?
>
> Cheers,
> Manuel
>
>

Re: [Pharo-users] New Pharo Booklet

[Dimitris Chloupis]

Pillar supports embedding LaTex and HTML inside your pillar files so
whatever works for those should work for Pillar. Pillar also has templates
you can modify via moustache. Pillar is actually so flexible I used as a
static website generator utilizing moustache and bootstrap and worked like
a charm. It’s syntax is just the tip of the iceberg.

On Wed, 1 Nov 2017 at 06:39, Hernán Morales Durand 
wrote:

> Thank you Stef!
>
> I wrote documentation for my packages in Markdown + pandoc + LaTeX.
>
> The TeX macros contains syntax colorization for Smalltalk code which
> can be easily added to Pillar (I suppose)
> Would you consider adding the syntax coloring from the TeX macros I sent
> to you?
>
> I have some silly questions about Pillar:
>
> The documents can be integrated with toc through pandoc, can this be
> done in Pillar?
> For tables I use tabu, longtable, booktabs, what to use in Pillar?
> For multiple language suppor I use fontspec and lmodern, what to use in
> Pillar?
> For link I use hyperref, what to use in Pillar?
>
> I have some chapters ready and I would love to be published in a book,
> under the umbrella of Pharo Books:
>
> https://github.com/hernanmd/Territorial/raw/master/Territorial.pdf
> http://biosmalltalk.github.io/web/doc/BioSmalltalk-1.0.pdf
>
> https://github.com/PhyloclassTalk/phyloclasstalk.github.io/raw/master/doc/PhyloclassTalk-1.0.pdf
>
> What do you think?
>
> Cheers
>
> Hernán
>
>
> 2017-10-29 17:53 GMT-03:00 Stephane Ducasse :
> > Hi guys
> >
> > I just published a new little booklet on Pharo tips and tricks!
> > Available at: http://books.pharo.org
> >
> > Feedback and contributions are welcome as usual.
> >
> > Stef
> >
>
>

Re: [Pharo-users] Writing "powerpoint" like presentations in Pharo?

[Dimitris Chloupis]

Oh there is also the possibility this is already available via GTInspector,
last time I checked I remember it having a slideshow preview of images
collection and it embeds a workspace as well. So maybe you already have
what you need.
On Wed, 1 Nov 2017 at 22:57, Dimitris Chloupis <kilon.al...@gmail.com>
wrote:

> Well technically this is easy to do with Morphic. Probably Spec 2. Doing
> it from inside the Pharo window will give you the ability to demonstrate
> live code and Morphic is live code.
>
> If you don’t want to do everything with Morphic you can create this in any
> app of your choosing , export to images and have Morphic load those images.
> I don’t see why this would take more than a couple of hours to prepare ,
> the actual Morphic code should not take more than 20 minutes.
>
> It a simple case of a SystemWindowMorph embedding a couple of button morph
> (for going forward and backward) and an ImageMorph. Plus a timer if you
> want the slides to proceed automatically.
>
> If you feel adventurous you can do this entirely on Morphic , again should
> not take you more than two hours total together with content creation.
> TextMorph should be more than enough.
>
> I would have said use Pillar but in this case it’s an overkill and Pillar
> does not allow for the precise positioning of images like Morphic does.
> On Wed, 1 Nov 2017 at 20:35, Tim Mackinnon <tim@testit.works> wrote:
>
>> Hi - has anyone made anything where you can create a full screen
>> presentation in Pharo with slides with some large text, bullet points and
>> embedded pictures - but then it’s a facade that lets you evaluate items in
>> the slide or jump to any code mentioned?
>>
>> Sort of like what Alan Kay does in the eToys images?
>>
>> I need to do a presentation next week and I always loved it when I was
>> fooled into thinking I was looking at a static’ish powerpoint and then
>> suddenly realised it was a live environment.
>>
>> It doesn’t sound that hard to do something simple - but I’m not sure if I
>> can pull it off in time for my presentation. But am curious if we have
>> something.
>>
>> (For bonus points, GT-Spotter stuff would work in it over top of the
>> presentation to demonstrate simple things)
>>
>> Tim
>>
>

Re: [Pharo-users] Writing "powerpoint" like presentations in Pharo?

[Dimitris Chloupis]

Well technically this is easy to do with Morphic. Probably Spec 2. Doing it
from inside the Pharo window will give you the ability to demonstrate live
code and Morphic is live code.

If you don’t want to do everything with Morphic you can create this in any
app of your choosing , export to images and have Morphic load those images.
I don’t see why this would take more than a couple of hours to prepare ,
the actual Morphic code should not take more than 20 minutes.

It a simple case of a SystemWindowMorph embedding a couple of button morph
(for going forward and backward) and an ImageMorph. Plus a timer if you
want the slides to proceed automatically.

If you feel adventurous you can do this entirely on Morphic , again should
not take you more than two hours total together with content creation.
TextMorph should be more than enough.

I would have said use Pillar but in this case it’s an overkill and Pillar
does not allow for the precise positioning of images like Morphic does.
On Wed, 1 Nov 2017 at 20:35, Tim Mackinnon  wrote:

> Hi - has anyone made anything where you can create a full screen
> presentation in Pharo with slides with some large text, bullet points and
> embedded pictures - but then it’s a facade that lets you evaluate items in
> the slide or jump to any code mentioned?
>
> Sort of like what Alan Kay does in the eToys images?
>
> I need to do a presentation next week and I always loved it when I was
> fooled into thinking I was looking at a static’ish powerpoint and then
> suddenly realised it was a live environment.
>
> It doesn’t sound that hard to do something simple - but I’m not sure if I
> can pull it off in time for my presentation. But am curious if we have
> something.
>
> (For bonus points, GT-Spotter stuff would work in it over top of the
> presentation to demonstrate simple things)
>
> Tim
>

Re: [Pharo-users] Return value of a FFI call to a external function is its 2`s complement

[Dimitris Chloupis]

Ah ok I know that one, just did not know it was named "two's complement" ,
looks to me normal error. I have seen this value many times in case of
errors while debugging C code with GBP

It returns error probably because of the reason I outlined in my previous
reply.

On Mon, Oct 30, 2017 at 3:51 PM Paulo R. Dellani <dell...@pobox.com> wrote:

> "Two`s complement" is one possible way to represent signed integers in
> binary form (1).
>
> When the message apiZmqMsgRecv: message socket: socket withFlags: flags is
> sent, as
> shown in my prior message, a function from libzmq, zmq_msg_recv (2) is
> called
> and the return value should be either the number of bytes in the received
> message
> or -1, in case of an error. Well, I was expecting to get a -1 as return
> value when
> calling the function in non-blocking mode, but it returns 0x,
> which happens
> to be the 2's complement representation of -1. At least the old code for
> libZMQ
> was not expecting that.
>
> Cheers, Paulo
>
> (1) https://en.wikipedia.org/wiki/Two's_complement
> (2) http://api.zeromq.org/4-2:zmq-msg-recv
>
>
> On 10/30/2017 02:13 PM, Dimitris Chloupis wrote:
>
>
> I have no idea what you mean by "2's complement"
>
> In any case bare in mind that UFFI has a limited range of C types that
> does support. Here you use 2 custom types , ZmqApiMessage and ZmqApiSocket
> , both are pointers because of * . Now these types are definetly not
> included with UFFI so if you have not done so you will have to
>
> 1) Define a class that inherits from FFIExternalObject and make sure your
> class handles the pointer properly
> 2) Replace the custom type with an equivelant type that is supported by
> UFFI
>
> The type of the pointer does not affect the pointer itself, usually, but
> rather the data it points to. So a pointer knows from it type that the data
> consumes a x amount of bytes and is of specific type , this can help also
> with indexing as C arrays are nothing more than a pointer that uses the
> index as an offset depending on its type of x amount of bytes.
>
> So its crucial that you get these right or else you going have some super
> weird results and even crashes.
>
> Because if you use improper types the pointer will give access to an area
> of memory bigger or smaller than the inteded type . Smaller will give you
> corrupted data (you will be missing bytes of data), bigger may crash
> because it may extend to area of memory not allowed to access.
>
> Technically speaking you can use even incorrect types if you know what you
> doing because UFFI pointers have great flexibility allowing you define real
> time the excact position of the memory and the range.
>
> Bare in mind that C is a high level language (and not low level as many
> incorrect assume) and deal with types that is NOT a low level concept
> (excepts types that have to do only with the size/ amount of bits) . So the
> type gives crucial information to C how exactly to access the memory.
> On Mon, Oct 30, 2017 at 2:03 PM Paulo R. Dellani <dell...@pobox.com>
> wrote:
>
>> Dear uFFI experts,
>>
>> I am dealing with the port of the ZeroMQ
>> <http://smalltalkhub.com/#%21/%7Epanuw/zeromq> code to Pharo 6 and found
>> something unexpected to me, at least:
>>
>> Zmq4Api>>apiZmqMsgRecv: message socket: socket withFlags: flags
>> ^ self ffiCall: #(long zmq_msg_recv (ZmqApiMessage* message,
>> ZmqApiSocket* socket, long flags ) )
>>
>> Calling this returns the 2's complement of the return value
>> of the external function call. Is it expected that the code calling
>> this do the decoding of the 2'complement representation of
>> the return value?
>>
>> Cheers,
>>
>> Paulo
>>
>
>

Re: [Pharo-users] Smalltalk Argument

[Dimitris Chloupis]

On Sat, Oct 28, 2017 at 6:10 AM Andrew Glynn  wrote:

> Web dev is a messy field.  Not because it has grown too fast, but because
> it was designed by amateurs, developed by amateurs, and continues to be so,
> while depending on an underlying expertly designed system, the internet.
>

 Non sense. Companies have been heavily involved in the developing of the
web since day one. Javascript was not designed by an amateur and pretty
much no web dev technologies out there not only are produced since day 1
from professional coders , web standards committess played a crucial  role
in the developing of web technologies.

The web has always been a huge cash cow.

The very fact that Javascript has the name Java is not as many developers
will be quick to point unrelated Java. It is very much related. . Sun for a
considerable amount of time was working on Javascript as a scripting engine
targeting the web working hand in hand with Java. The relationship was sort
lived but for a very long time Java was the de facto language for
developing powerful web application / websites. The well known Java applets
that exist even today.

The reason why the web followed its own road is quite sensible. The
internet was viewed as nothing more than a display of documents and made
sense to use a document format (HTML) for it at the time. It was easy and
accesible to anyone. None could predict the explosion of the web at the
time and the future needs for much greater degree of dynamism. Neither
could I and I am vicious critic of web dev.

The technology evolved very fast that not even up for debate, good designs
require redesigns. Redesigns require time.

The web was nothing really new neither was the internet. BBS were
dominating online communication and function in a very similar way that the
web did later on providing, email, messages, forumes, download directories,
blog posts, articles and a wealth of information through the use of a model
and a regular telophone line. BBS were based on desktop technology and far
better designed but they could not keep up with the incrasing demands of
massive online communication so the web and the internet ignated even
though internet was create far earlier than BBS. Much less likely to find
cat videos because BBS was based on P2P kind of technology and was working
on very limited hardware where every byte was precious.

It was the failure of desktop technologies to adjust to the need for a web
that lead to its seperate evolution. Java was the only language that took a
serious interest into web developing and even Java was unwilling to adjust
to the needs of the web leading to the massive failure of the Java applet.
On the other hand Flash that was specifically designed for the web ,
flourished for many years till HTML and JS finally caught up.

Amateurs also play a very importan role in the evolution of graphics and
guis. Teenage hackers were the ones to ignite the trend of computer
graphics that lead to the establishment of GUI and 3d graphics as well as
computer audio even though those technologies have existed far earlier it
was their innovation that managed to take advantage of clever solution to
overcome extreme limitations of the hardware. This happened through the
developing of "demos" giving rise to a completely new community of extrmely
knowledgable amateurs knows as "demoscene" and hackers. 3d graphics to this
day remain the most fast moving / evolving field of computer science
challanged only by AI.

Plus Amateurs play a vital role in many other fields like Astronomy , their
contribution is so substabtial that many celestial bodies are named after
them. Amateurs have usually far higher level of knowledge of a field mainly
because they tend to avoid specialisation and they do not operate on the
time constraints or have to fight a backward thinking management department
that want to do things "the popular" way. For similar reason they pay far
more respect to designs as well.

So it was both the failure of desktop to take into serious consideration
the new web needs and the rapid evolution of the web based on the format
that it was already problematic.

It was companies themselves that hindered and keep hindering its evolution
with being stuck on bad design for the shake of backward compatibility.

On the other hand desktop has it own share of ugliness and "amateurism"
biggest example being MFC , Microsoft's Official GUI API, that was so ugly
and heavily disliked that none even question the existence of HTML because
no coder in his right mind could consider imposing such a terrible design
to a new technology.

On similar note web is not all that bad, JS has heavily improved as a
language , HTML has become extremely flexible and there are many well
designed libraries like Bootstrap , D3 etc . Also desktop language learned
their lesson and now fully embreace web dev at least on the back end.

Finally nowdays we see the merging of web and desktop technlogies (and the

Re: [Pharo-users] UFFI and Fortran

[Dimitris Chloupis]

Maybe you talk about TalkFFI which aumatically wrapped C libraries for
Pharo and i think Squeak as well but used Nativeboos, i think

http://forum.world.st/TalkFFI-automatic-FFI-generation-for-Pharo-td4662239.html

On the subject of Fortran yes you can use UFFI if Fortran code is compiled
as a DLL (or equivelant non Windoom OSes)

https://software.intel.com/en-us/node/535305

Dynamic Library format are not exclusive to C for generation , many
languages can generate them so even though UFFI is used predominatly for C
any language that can generate a DLL without any name mangling should be
accessible via UFFI.

if DLL generation is not possible, then you can drop down to my solution of
Shared Memory Mapped Files. Which means you make an executable in Frotran
(or any other language)  that contains the code you want to access and
creates a shared memory region and you can access that region from Pharo
via UFFI.

This is how I built my CPPBridge project. Which one can use as a template
for generating similar bridge for Fortran or any other language where the
generation of DLLs is not practical or possible.

The shared memory region can be used also as a means of communication
additional to sharing live state, memory mapped files automatically save
the live state so next time you open the file it behaves as you would
expect a Pharo image to behave by restoring the live state. A means to
extend Pharo image to include memory not managed by the VM.

Because memory mapped files is mechanism of the OS Kernel and is also the
mechanism used for the loading of dynamic libraries like DLLs there is also
no loss of performance and is the fastest way of communication between
languages, libraries and applications.

So yes using Fortran code is possible via UFFI in more than one way.

But in the end it should be noted here that because IPC mechanisms (common
way of using libraries from other languages) are based on core OS
functionality like , memory managment, sockets , pipes, etc its not hard to
use libraries from any language from inside any language.

So Pharo can use Fortran libraries and Fortran can use Pharo libraries, its
also possible to retain live coding even when executing code written in
another language through various means. Recently I was succesful in making
Python into a basic live coding enviroment , meaning code that when changed
in the source file it updates also existing live intances as you expect in
Pharo. Python also supports memory mapped files so its possible to create a
joined live coding enviroment and live image that containes both Pharo and
Python bytecode. Of course without touching VM source code.

Even though live state is not tricky to retain for compiled languages, live
code can be a bit trickier to do but still not impossible or that hard as
most would assume.

Sky is the limit.

Bottom line is that if you have a favorite library in any language you can
use it from inside Pharo with at worst a few hundrend lines of setup code
you can create as a library and of coure reuse next time you want to use
again a library from another language without having to write a line of
additional code. The technology is available is just a matter of learning
how to use it.  Especially if its a very large libraries it will be
thousands times easier than trying to replicate the functionality in Pharo.



On Fri, Oct 27, 2017 at 6:26 PM Sean P. DeNigris 
wrote:

> Ben Coman wrote
> > it seems to hint how to do it from Pharo UFFI.
>
> Slightly OT: I remember years ago, someone (Dave Mason?) demoed a library
> which automatically created FFI wrappers for C libs. I never heard anything
> about it after that, which is sad, because I was amazed and wanted to use
> it!
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

Re: [Pharo-users] Annual online conference?

[Dimitris Chloupis]

indeed excellent idea

Having a polished website like they did, is the way to go.

+1

On Thu, Oct 26, 2017 at 11:54 AM Tudor Girba  wrote:

> Nice idea, indeed.
>
> Doru
>
>
> > On Oct 26, 2017, at 10:18 AM, Marcus Denker 
> wrote:
> >
> > That’s a nice idea!
> >
> > I will check how they did it and we should see if that makes sense in
> the future.
> > (for Pharo Days)
> >
> >   Marcus
> >
> >> On 25 Oct 2017, at 23:17, PAUL DEBRUICKER  wrote:
> >>
> >> Laravel.com is a PHP web framework.
> >>
> >>
> >> Their community organizes an online conference:
> https://laracon.net/2017
> >>
> >>
> >> Seems like it could be worthy of mimicking in the Smalltalk community.
> >>
> >
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "In a world where everything is moving ever faster,
> one might have better chances to win by moving slower."
>
>
>
>
>
>

Re: [Pharo-users] Smalltalk Argument

[Dimitris Chloupis]

Well all languages have well designed and badly designed libraries , in
Pharo you dont even have to look hard just take a look at Morph and Object
class and awe at all those irrelevant methods trying to cram in features
you will probably never use. Especially my experience with Morphic has been
as nightmarish as my experience with MFC. And MFC is a C++ library and made
by Microsoft. On the other hand QT is a brilliantly designed GUI API (again
for C++) and dont even get me started on DELPHI libraries which to this day
I consider top when it comes to OO libraries. together with its IDE (but I
never liked its language).

Web dev may be a messy field mainly because it has grown too fast, after
the web explosion ,  based on problematic concepts but desktop libraries
and as a consequence mobile dev libraries (iOS is a variable of MacoOS,
Android a variant of Linux) in a much , much better position and some of
them have stellar designs. Mainly because are far more mature with decades
of extremely active development.

Of course many of those great design are the result of a reaction to bad
designs and lessons learned from other APIs. There is no good design
without a redesign.

My personal opinion is that as pessimistic it may sound, Smalltalk has very
little to offer in the library front. The language is still stellar and
live environment is a great concept but from there on there is a decline.
Sure if your are low demand kind of person on the library front and dont
mind implementing stuff by yourself you wont mind the lack of libraries but
most coders , me included , dont have this luxury. Especially making a
living with a language is a completely different story from learning it as
a hobby,

I think and that's a personal opinion, that Smalltalk goes the wrong
direction. It tries to be a do it all language, but we already have an army
of do it all languages. I think it would excel as the backbone in big
complex projects. Like the Moose project is doing with code analysis and
visualization. I think this is an excellent direction to go with Smalltalk.
Reflection is the big strength of Smalltalk the ability to communicate with
its code in a direct matter. So I think that a Smalltalk implementation
that can analyze and visualize code written in other languages would have
been a pretty serious reason for people to learn Smalltalk.

I am very happy to see Pharo go towards that direction and yes I would
definitely recommend it without hesitation  for code analysis and project
management tool. Its no coincidence that we have seen a serious growth in
our community. When I joined back in 2011 we all were posting at pharo-dev,
pharo-users was a dead zone and then the community grow larger and larger
we soon may need a third mailing list.

Code complexity is an issues for all large projects and tools that help
manage this without having to convert to another language are very
popular.




On Thu, Oct 26, 2017 at 3:14 PM jtuc...@objektfabrik.de <
jtuc...@objektfabrik.de> wrote:

> Andrew,
>
> Am 26.10.17 um 00:46 schrieb Andrew Glynn:
>
> There’s other questions that are relevant to me:
>
> I am glad you opened your words with this sentence. Other peoples'
> mileages may vary a lot.
>
>
> > Do I give a f*** about cool looking web apps?  No, I don’t use web apps
> if in any way I can avoid it.
>
>
> Some people can't. I can't. I am making my living with a web based
> application. And I like it.
>
>
> > Do I give a f*** about mobile apps?  No, the screen’s too small to read
> anything longer than a twit, or anyone with anything worthwhile to say.>
>
> So you are in the lucky position that neither mobile nor web nor
> integration matters to you or you have enough resources to do all that
> stuff yourself. I am envyous. I need to build web pages and people ask me
> whether we can ship an iPhone App. I do customer-facing stuff and sex sells
> much more than we like to think.
>
> Your comments on the crappiness of libs in other languages is a great fit
> for Smalltalk. Not invented here, therefor rubbish. We came a long way with
> this way of thinking. But these rubbish makers dance circles around us
> while we try to do our first hello world for an iPad. They laugh at us when
> we try to reinvent MVC on top of Seaside (although MVC is closesly related
> to Smalltalk). Because they are back home and watch Netflix while we debug
> our homegrown base libraries that are, of course, much better than theirs
> because they are written in Smalltalk.
>
> I am not arguing that maintaining Smalltalk code is far superior to most
> technolgies out there. But depending on the needs of our projects we have
> to learn and use those crappy technologies to accomplish what they offer.
> Because, sometimes (especially if you have to pay bills), an existing
> library with flaws is better than none.
>
> So if I have to use Javascript or C# or Dart or Swift to do the frontend
> part of my system, is there still much benefit in using these together 

Re: [Pharo-users] Exchanging information between 2 pharo applications (2 images running on two different computers)

[Dimitris Chloupis]

Nothing complex about two images exchanging messages, its not even complex
to transmit objects via fuel, you even transmit a debugger or any part of
the live environment or even make an "internet" of images that join objects
together. Sky is the limit. Pharo already provides you will all the
tools/libraries to do this.

A streamsocket (not to be confused with regular sockets) will delay the
messages (a collection of bytes) until they arrive to the receiver or until
they have reached the timeout period. Offline mode is pretty much
obligatory even for plain old internet web apps because of drops in
connection or the plain fact a connection can become slow.

I used streamsockets in my Pharo to Python bridge (Atlas) because the
execution was not necessary synchronous , I was sending Python command to a
3d application from Pharo and I had to make sure that the bridge was
working even in the case of a command that could take hours to execute like
a rendering process.

One cool trick I did was to send the Python errors back to Pharo and
trigger them as Pharo's regular MessageNotUnderstood , this is a nice way
to make sure that you can fix a wrong message after it has been executing
without going to the image that is executing it.

The limitation with sockets which what every frameworks uses because AFAIK
they are the only means to communicate remotely is that they are not top
performance so that mean that you can send long loops but executing
communication inside long loops will either slow you down considerably or
simply timeout your socket. Sockets can timeout from both ends if they feel
that for some reason they lost communication with the other side and
reached their timeout period. Timeout period is customization.

This is a problem I did not tackle with my implementation because I dont
think there can be an actual practical solution better than avoiding this
scenario.

Only shared memory seems to overcome this but it can be used only locally
and not remotely (aka on same computer) .

On Wed, Oct 25, 2017 at 4:41 PM Cédrick Béler  wrote:

> I had a look and this is not (natively) possible.
>
> The idea of the off-line mode would be to delay messages that are sent to
> the peer until a connection is established.
>
> I think I have to try to do it by myself (like having a list of
> information exchange that wait until a connexion is established).
>
> What I try to do is not as complex as two general image exchanging
> messages on objects (like on TelePharo).
>
> I just want a repository of information (mainly a collection of static
> information/data versions) on both peers to be synchronized when a
> connection is established.
>
>
>
>
>
> Le 25 oct. 2017 à 15:31, Denis Kudriashov  a écrit :
>
> What is offline mode?
>
> 2017-10-25 15:10 GMT+02:00 Cédrick Béler :
>
>> Thanks Denis. I will !  I knew I have seen a telephoto component that
>> could help but forgot about it !
>>
>> Do you know if it’s possible to handle offline mode ?
>>
>>
>>
>> Le 25 oct. 2017 à 15:05, Denis Kudriashov  a écrit
>> :
>>
>> Look at Seamless https://github.com/dionisiydk/Seamless.
>>
>> 2017-10-25 14:21 GMT+02:00 Cédrick Béler :
>>
>>> Hi all,
>>>
>>> I want to connect two applications (1 by image, each one on a different
>>> computer) so as as to exchange information (data) between them.
>>>
>>> So my question is about the best (smalltalk) practices to connect two
>>> app/image and exchange data.
>>>
>>> I imagine either with a direct connection through a network (TCP Socket,
>>> Web socket, pure HTTP with Zinc) and/or with a serial connection.
>>> At first, without any « security ». But later, information exchanges
>>> will be encrypted.
>>>
>>> I’ve seen some information on how to use SerialPort, or even FileStream.
>>> I could do it (or at least simulate it with HTTP). What are the other
>>> options ? Socket ?
>>> Do we have P2P libs (I couldn’t find) with eventually discovery features
>>> ?
>>>
>>> Any comment / suggestion / pointers are greatly welcome.
>>>
>>> TIA.
>>>
>>> Cédrick
>>>
>>
>>
>>
>
>

Re: [Pharo-users] Multi-core Software Concurrency

[Dimitris Chloupis]

It all comes down to what you mean by "efficient". Obviously if you want
top performance on multiple cores you dont use any of those languages
including Pharo. Thats prettty much the sole reason why C++ is still a
relevant language.

Now if you want ok performance you could use those languages.

However in real case scenarios if you are worried about multi core support
then you have performance issues that you have to make sure its not the
code that has to be blamed before the language.

For example yesterday I was loading a PNG file via Python to display on
screen via OpenGL and I was getting very slow performance 2.7 second for
1.5 mb PNG. So my assumption as always "super slow python". But I decided
to give a try to another Python library and expected no more than 1.5 - 2
seconds load time for the same file. It loaded in 0.03 seconds and took
some time to collect my jaw from the floor.

Of course the previous library used a "pure python" approach , the other
library was the usual C library wrapped for Python.

So the library and the code plays a massive role, and I mention this
example because Pharo works in a very similar way. If you do the code in
pure Pharo, Elixir or whatever you will be hit by the performance whale of
dynamic languages. Dynamic typing comes with a high cost as does a live
coding enviroment. Pharo is very lucky in that it has a JIT VM espeically
optimised for its language, so generally you wont get the slow speeds I
got. But still C will once more run circles around a Pharo implementation ,
especially if its an optimised library.

Thus we have the UFFI. Esteban has done an excellent job and works like a
charm for using C libraries.

Now if C also is proven slow then multi core wont help you much.

You need the big guns , which is another name for "GPUs". A powerful GPU is
even hundrends time faster than the most powerful CPU because it has
thousands of cores. But those cores are designed to compute similar tasks
hence why we dont throw CPUs away which are more versatile.

So if you plan to do similar computations through millions of objects,
multi core wont help you much, you need the big guns a very expensive and
powerful GPU to do the heavy lifting.

GPUs used to specialise only on Graphics, but 3d has become so complex that
nowdays they can do all sort of computations and they have dedicate APIs
for accesing thousands of cores via OpenCL and CUDA.

Unsuprisingly they run mainly on C/C++.

The good news is that through the UFFI is possible to access a GPU via
Pharo, Ronie has done this.

But to my experience most people dont realise what an extremely complex
field performance is and how it widely fluctuates from scenario to
scenario. So there is no "turbo" button to press.

Now if you ask "but how I do this with pharo". Well technically you dont do
this with Pharo because Pharo is made to run on CPU.

GPUs run their own executables which means you have to use special
compilers , good news is that they can do compiling on the fly too so Pharo
can leverage that. Again Ronie's works is relevant here.

If you want to avoid all the complexity and go for the simplest solution ,
then avoid the GPU. Because GPUs are kinda insane in terms of complexity.

The easiest way is to fire up multiple Pharo and have them communicate with
each other via socket or shared memory. The OS when it starts a new process
it usually asigns it a core that is idle to take advantage of your multiple
cores.

Summary:
The answer is "Pharo can do this by accessing the GPU which much faster
than CPU or can access multiple cores through multiple instances running at
the same time".

So yes you can have top performance Pharo code if run this way, it wont be
up to C standards but it will be blazzing fast none the less.

On Mon, Oct 23, 2017 at 4:28 PM horrido  wrote:

> With today’s powerful multi-core processors, the demand for efficient
> software concurrency is high. We find strong support for such concurrency
> in
> the latest crop of “modern” languages such as Clojure, Elixir, Go, Haskell,
> and Scala.
>
> Whenever I present Smalltalk (Pharo) as a great language option, inevitably
> someone asks me about multi-core software concurrency. I have no response
> for them.
>
> Do I just say that if you need concurrency, Pharo is the wrong choice?
> After
> all, no programming language can be good at everything. You must always
> choose the right tool for the job.
>
> Do I say that doing concurrency right is very, very tough, even for the
> most
> experienced of developers? Let's focus on Pharo's strengths, instead.
> Sounds
> like an excuse.
>
> Can we safely ignore the multi-core reality? I welcome your feedback.
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

Re: [Pharo-users] Smalltalk Argument

[Dimitris Chloupis]

Actually you need to read the small letters bellow the graph

"% of developers who are developing with the language or technology and
have expressed interest in continuing to develop with it"

which means basically "Smalltalkers love Smalltalk !!!|" . Actually I am
surpised its only 67% of Smalltalkers that actually love Smalltalk and that
Rust comes first. I was expecting a 90%. But then Rust has been the most
hyped language these past few years.

But does not change the fact that maybe 99% of the coders have not even
heard of Smalltalk and a 60% of Rust.

The bottom line is that the excuses for not using a language can no longer
stand in 2017
(1) But I wont find coders for it
(2) But I wont find libraries for it
(3) But I wont find documentation for it

Let's take (1) , why you even need to find someone that already knows the
language? Do we realise there are people with zero coding experience that
have made built milti million dollar empires . Almost 2 decades ago I
remember reading about q surfer that loved to surf but also made surf
boards. So inside his naiveness said "well let's make an e-shop" and he
made alone one of the first e-shops selling surf boards and he made
millions.

So we have this guy that knows nothing about coding, I think I remember him
saying that he did not even know how to use a computer before, on one side
that in a period of few years has made a multi million dollars software.

On the other side we have experienced coders, that most likely have battled
with code bases of millions of lines of code , university degree, masters
and doctorate and they cannot do what a surfer did ? Seriously

(2) That's my favourite , libraries. We live in 2017 when even my
grandmother's language run on JVM and has JS compiler and we still debate
libraries availability ? Seriously. You can use ANY library from ANY
language and is not even hard. I made Pharo use Python libraries and it
took me a few hundreds lines of code just to make a simple socket bridge.

(3) This one is the most logical, even when I i started coding in Pharo and
to be fair Pharo was still on very early releases there was minimal
documentation and the one I found was outdated. Still no problemo, I am a
coder, I can read code. You will be reading tons and tons of code anyway,
documentation in any language will never take you far.
Why ?
Because the vast majority of users prefer the easy and generic features. A
minority of people dive deep into a library and the ones they do rare
document it.
You are more likely to find specialised information in mailing and forums
than in documentation documents. Of course even there you may get no answer
so you end up testing and learning yourself. Wont mattter even if it is
Java.

Plus there are tons and ton of project made in languages very unpopular
that did great, Ruby On Rails is an example. One library it was all it took
to put Ruby on map.

Even C was introduce through the Unix operating system. New language, out
of nowhere and wait those people using an unknown language wanted to make
one of the best OSes of all time.

So no, even though I rarely get into a language debate because of how
religious people , there is no for not using Pharo but any unpopular
language out there. Because in the end what it will matter the most is the
determination of the coder to output efficient code. If you are passionate
about something nothing can stop you and especially these bad excuses.
Pretty much the most important ingredient for any very successful software
product.

On Fri, Oct 20, 2017 at 11:37 AM Paulo R. Dellani  wrote:

> I also do not believe my eyes:
>
>
> https://insights.stackoverflow.com/survey/2017#most-loved-dreaded-and-wanted
>
>
> On 10/20/2017 10:20 AM, Marten Feldtmann wrote:
> > I do not want to spoil the party (perhaps I've done this already) - but
> > has anyone done a serious inspection of this number: 67%.
> >
> > They have interviewed 64000 persons and 67% of the people should "love"
> > Smalltalk? Come on, that seems to be not possible. Perhaps 67% of the
> > user already using Smalltalk "love" that.
> >
> > By the way - the most loved platform is Linux (69%) ...
> >
> >
> > Marten
> >
> > Am 20.10.2017 um 09:19 schrieb Paulo R. Dellani:
> >
> >> The second most loved language by 67% of developers surveyed cannot
> simply
> >> be ruled out because of unfounded concerns. (Thanks again for the
> >
>
>
>

Re: [Pharo-users] Smalltalk Argument

[Dimitris Chloupis]

I would have followed the Python approach.

When Guido created Python , it did not try to convince his co-workers about
how superior it was compared to other languages. At the time he did not
intend to use it even as programming language. That worked to his
advantage. Instead it used it for small tasks, usually tiny command line
utilities that none would notice. But some did notice and expressed
interest , they tried Python for small tiny tasks again mainly command line
utilities. The co workers came back with suggestions how to improve it and
the rest as they say it’s history.

Any project has cracks that you can squeeze another language , the curious
will the express interest and wonder “what this Pharo is ?”. I think that
probably the best way to promote a language instead of trying to convince
them how great it is. When language is used for such small tasks none will
ask where they will find Smalltalk devs because it’s easy to learn any
language for very simple tasks.  Humans are curious by nature and they love
a nice mystery.

You don’t have to convert an entire project to Pharo, the import thing is
to ignite interest.

Or as the saying goes “actions speak louder than words” ;)

On Thu, 19 Oct 2017 at 10:05, Paulo R. Dellani  wrote:

> Dear all,
>
> after using Smalltalk for several years I developed a passion for the
> language (how not to?), and Pharo is just so great to develop with.
> So thank you guys for keeping this wonderful project running.
>
> Unfortunately, it is not easy to always point out why Smalltalk
> should be employed as "main development language" in a team
> or for a project. In the last discussion of this sort I was confronted
> with the question "where are we going to get new smalltalk
> developers if our startup grows or if you go?". Well, I had no
> good answer to that. What would have you answered?
>
> Cheers,
>
> Paulo
>
>
>

Re: [Pharo-users] Pharo and instance variables ...

[Dimitris Chloupis]

Well the method of the receiver can check for the type of the object from
which you receive a message, technically you can restrict the access even
to a particular instance object. You can enforce a ton of restrictions as
the entire system is modifiable and live.

On Wed, Oct 18, 2017 at 8:37 AM Prof. Andrew P. Black 
wrote:

>
> On 18 Oct 2017, at 08:32 , James Ladd  wrote:
>
> What if accessors were generated but not mutators?
>
>
> The point is that, once a method exists, there is not way to restrict who
> can send a message that will execute it.  So if one were forces to generate
> a reader method, or a writer method, just to give access to a subclass,
> then *every* object n the system would also gain access.
>
> Andrew
>
>
>

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[Dimitris Chloupis]

So I finally built the Python live coding library I was talking about. I
named it "pylivecoding"

https://github.com/kilon/pylivecoding

Live codig does mean in this case , replace methosd with updated ones for
each instance of a class. Same thing you would expect in Pharo. Very simple
to use , only 50 lines of code.

it can also work with not only modifying methods , but aslo renaming them
and removing or adding new ones. I have tested it during the day, seems to
work ok but of course more thoroug testing needs to be done.

Of course nowhere near the Pharo experience. But the main idea is there,
you open yoru favorite editor IDE, you code away and at the same time you
see your code come alive with no delays or weird side effects/ requirements.

Of course it works with debuggers too, I use it from my python ide, python
debugger and iptyhon all the time. Again usual workflow , debug, correct,
continue. No issues so far.


On Sat, Oct 14, 2017 at 4:37 AM Dimitris Chloupis <kilon.al...@gmail.com>
wrote:

> I don’t care about Python vs Pharo debate. I love both I use both.
>
> My ultimate goal is to unite the two under a single Uber powerful live
> coding environment part of my project Atlas. With direct mapping between
> Pharo and Python objects and no compromises. A workflow that will be
> seamless that you won’t know if you use Python or Pharo libraries as the
> Atlas environment will allow you to work with both languages in a symbiotic
> relationship.
>
> That was a dream of mine that I did not dear to reveal now slowly and
> steadily becomes reality.
>
> I am extending the live coding environment of python and later will tackle
> the subject of a python image format.
>
> Already Atlas can use python libraries from Pharo but that’s about it ,
> but after this revelation I can move to stage 2 of full synchronization
> between Python and Pharo. Even now Atlas allows you to use Pharo syntax to
> fully access Python libraries. But integration is skin deep and is what is
> going to improve the next years.
>
> So it seems something good came out of this very long discussion. Atlas is
> going for a big update. This thread has been a huge inspiration for me.
> Super excited :)
>
> On Sat, 14 Oct 2017 at 03:40, Andrew Glynn <aglyn...@gmail.com> wrote:
>
>> The first language I played with, I was nearly 5, was a live environment,
>> Forth. I used it on an old PDP my mother had bought that was being
>> surplused at the company she worked at. I used Forth until I was in my
>> early teens, it was far superior to the BASIC that most other kids I knew
>> who knew any programming used. It wasn't Smalltalk, but in many of the
>> areas it was used (production automation is one major area), the language
>> that most often replaced it *was* Smalltalk.
>>
>> The biggest difference, for me, as I wrote in the article the other day,
>> is the ability to build-on rather than build-with, which in turn is based
>> on the environment being written in itself. Ruby *looks* very much like
>> Smalltalk, but it *works* like Java; Python works *more* like Smalltalk,
>> and it's a much better live environment than Java or Ruby, because more of
>> it is written in itself, but too much of Python is written in C, and that
>> causes problems. If the code that interprets/compiles your code follows the
>> same rules, the machine code it generates will usually also follow the same
>> rules, and those rules/restrictions are, for the most part, designed to
>> make code more reliable.
>>
>> As well, RVM has proven Smalltalk (specifically Squeak / Pharo, though
>> admittedly an older version) can scale to 1024 cores nearly linearly.
>>
>> Python has a decent developer base but it's almost all OSS and almost all
>> on Linux. Very few applications in Python are in areas where reliability is
>> absolutely necessary, or even all that important.  Like Smalltalk, it's a
>> general purpose language in a niche, but the niches are very different. For
>> years, decades really, any good version of Smalltalk cost an arm and a leg
>> (some of them both of each), and as a result it tended to be used only
>> where things really *had* to work.
>>
>> Pharo is a great OSS Smalltalk, IMHO by the best to date (Squeak was/is
>> good, but the LaF was never professional enough for it to be taken as
>> seriously as it deserves, it just looks too much like a toy although in
>> reality it's very powerful). Having the capability to build-on a reliable,
>> attractive and enjoyable base without signing over my great-grand-child's
>> first born is fantastic, and a great achievement for those who accomplished
>> it.
>>
>> Kendrick is an exampl

Re: [Pharo-users] "Building-With versus Building-on"

[Dimitris Chloupis]

I stand corrected

On Sat, 14 Oct 2017 at 08:11, jtuc...@objektfabrik.de <
jtuc...@objektfabrik.de> wrote:

>
>
> Am 12.10.17 um 20:04 schrieb Dimitris Chloupis:
> >
> > Eclispe , which I will disagree with your that is not the worst IDE,
> > started as a smalltalk IDE and then it got Eclipsed. I am sure those
> > people had a "build on" environment , still it got messy. We can blame
> > porting to Java, but can we really blame Java for the mess that is
> > called "Eclipse" e nope.
> >
> Eclipse was never implemented in Smalltalk. Its predecessor, VisualAge
> for Java (and parts of the other VisualAge family members) was. Eclipse
> was started as a replacement for VisualAge for Java because Java
> develoers didn't like VisualAge for its emulation of an image based
> environement. It was a very nice IDE for Java (the best I've known), but
> it wasn't a nice home for developers who think in files.
> These days Eclipse, IMO, does emulate an image as good as possible, but
> nobody cares anymore, because it hides the fact and lets you think in
> files ;-)
>
> Joachim
>
>

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[Dimitris Chloupis]

I don’t care about Python vs Pharo debate. I love both I use both.

My ultimate goal is to unite the two under a single Uber powerful live
coding environment part of my project Atlas. With direct mapping between
Pharo and Python objects and no compromises. A workflow that will be
seamless that you won’t know if you use Python or Pharo libraries as the
Atlas environment will allow you to work with both languages in a symbiotic
relationship.

That was a dream of mine that I did not dear to reveal now slowly and
steadily becomes reality.

I am extending the live coding environment of python and later will tackle
the subject of a python image format.

Already Atlas can use python libraries from Pharo but that’s about it , but
after this revelation I can move to stage 2 of full synchronization between
Python and Pharo. Even now Atlas allows you to use Pharo syntax to fully
access Python libraries. But integration is skin deep and is what is going
to improve the next years.

So it seems something good came out of this very long discussion. Atlas is
going for a big update. This thread has been a huge inspiration for me.
Super excited :)

On Sat, 14 Oct 2017 at 03:40, Andrew Glynn <aglyn...@gmail.com> wrote:

> The first language I played with, I was nearly 5, was a live environment,
> Forth. I used it on an old PDP my mother had bought that was being
> surplused at the company she worked at. I used Forth until I was in my
> early teens, it was far superior to the BASIC that most other kids I knew
> who knew any programming used. It wasn't Smalltalk, but in many of the
> areas it was used (production automation is one major area), the language
> that most often replaced it *was* Smalltalk.
>
> The biggest difference, for me, as I wrote in the article the other day,
> is the ability to build-on rather than build-with, which in turn is based
> on the environment being written in itself. Ruby *looks* very much like
> Smalltalk, but it *works* like Java; Python works *more* like Smalltalk,
> and it's a much better live environment than Java or Ruby, because more of
> it is written in itself, but too much of Python is written in C, and that
> causes problems. If the code that interprets/compiles your code follows the
> same rules, the machine code it generates will usually also follow the same
> rules, and those rules/restrictions are, for the most part, designed to
> make code more reliable.
>
> As well, RVM has proven Smalltalk (specifically Squeak / Pharo, though
> admittedly an older version) can scale to 1024 cores nearly linearly.
>
> Python has a decent developer base but it's almost all OSS and almost all
> on Linux. Very few applications in Python are in areas where reliability is
> absolutely necessary, or even all that important.  Like Smalltalk, it's a
> general purpose language in a niche, but the niches are very different. For
> years, decades really, any good version of Smalltalk cost an arm and a leg
> (some of them both of each), and as a result it tended to be used only
> where things really *had* to work.
>
> Pharo is a great OSS Smalltalk, IMHO by the best to date (Squeak was/is
> good, but the LaF was never professional enough for it to be taken as
> seriously as it deserves, it just looks too much like a toy although in
> reality it's very powerful). Having the capability to build-on a reliable,
> attractive and enjoyable base without signing over my great-grand-child's
> first born is fantastic, and a great achievement for those who accomplished
> it.
>
> Kendrick is an example of what can be done if you build-*on*: it was
> built on Moose, which is built on Glamorous, which is built on Morphic,
> which itself is based on a couple of decades work olving the basic problems
> inherent to UI's and MVC-type UI's in particular. Kendrick itself was
> written in a very short time when you compare it with other epidemiology
> programs, *if* you only count the time spent on Kendrick itself. It's an
> inherently complex problem area, and it's a life or death problem area.
> That an application capable of working reliably enough to be trusted in
> that area was built in a short time, because it was built-on a couple of
> decades of OSS work, is a huge compliment to those who were involved.
>
> Unfortunately for me, I wasn't, ☺. But at least I can take advantage of it
> existence now.
>
> Andrew
>
>
>
>
>
>
>
>
>
> -Original Message-
>
> *Date*: Fri, 06 Oct 2017 21:18:28 +
> *Subject*: Re: [Pharo-users] Behold Pharo: The Modern Smalltalk
> *To*: Any question about pharo is welcome <pharo-users@lists.pharo.org
> <any%20question%20about%20pharo%20is%20welcome%20%3cpharo-us...@lists.pharo.org%3e>
> >
> Reply-to: Any question about pharo is welcome <pharo-users@lists.

Re: [Pharo-users] FYI about Pharo MOOC

[Dimitris Chloupis]

I have to confess I am a fan of the french accent english too , it has a
nice musicality in it
+1 for subtitles. I love accents, the more the better :D

On Fri, Oct 13, 2017 at 9:28 PM Stephane Ducasse 
wrote:

> In fact the files have two tracks.
>
>
> On Fri, Oct 13, 2017 at 8:13 PM, Andrew Glynn  wrote:
>
>> Oh good, glad the French version is still there.  I was starting to go
>> through it a couple of weeks ago and plan to continue starting this
>> weekend.  Although my mother tongue is English, at one point I was
>> fluently bilingual (both Quebecois and actual French), and it's a
>> chance to get some of it back while picking up information I've likely
>> missed
>> on less obvious features.
>>
>> I can understand French well enough, but the more I hear it spoken
>> the better. Reading/writing don't get rusty as easily.
>>
>> Of course speaking it would be even better, but I don't get many
>> chances to do so in Toronto ☺.
>>
>> Andrew
>>
>> -Original Message-
>>
>> Date: Fri, 13 Oct 2017 18:06:17 +0200
>> Subject: Re: [Pharo-users] FYI about Pharo MOOC
>> To: Any question about pharo is welcome 
>> Reply-to: Any question about pharo is welcome > us...@lists.pharo.org>
>> From: Stephane Ducasse 
>> The production company told us that it was super strange without our
>> voices.
>> Now you can also have the french + subtitles.
>>
>> On Fri, Oct 13,
>> 2017 at 2:42 PM, Ben Coman  wrote:
>>
>> I played C019SD-
>> W1-S1-EN-V1.mp4
>> and as well as the english voice, in the
>> background I
>> can still hear your
>> original french voice.
>> I'm curious the
>> rea
>> soning for
>> this.
>>
>> cheers -ben
>>
>>
>> On Fri, Oct 13, 2017 at 3:59 AM, Stephane Ducasse > haro.s...@gmail.com>
>> wrote:
>>
>> I'm about to release the en versions.
>> you can
>> find them unofficially on http://www.stephaneducasse.eu/MOOC/
>>
>> Stef
>>
>> On
>> Tue, Oct 10, 2017 at 10:10 PM, Gour  wrote:
>>
>> On Tue,
>> 10 Oct 2017 21:31:55 +0200
>> Stephane Ducasse
>> 
>> wrote:
>>
>> Hello Stef,
>>
>> I will ask one guy thursday and let you know.
>>
>>
>> Thanks a
>> lot!
>>
>> We will release Mooc with english voices (not mine else english
>> nati
>> ves would get an heart attack - I have what they call a sexy
>> french
>> accents ;)
>>
>>
>> I did watch few of your Pharo-related presentations and,
>> although not
>> native,
>> happily survived. :-)
>>
>> Moreover, I'd say that your
>> English is charming! At least, one is sure
>> that the
>> real human is
>> speaking and not some "robot" put on auto-pilot, so if the
>> new
>> Mooc is
>> going to be the same as the  current/old one, I'd prefer to
>> download
>> the
>> current files and watched them along with *.srt subtitles?
>>
>> Iow. my point
>> is that the accent is just one part of the talk/teaching,
>> but the
>> energy
>> behind it is much more imporant - this is, my conviction, based
>> on my
>> own
>> teaching experiences.
>>
>>
>> Sincerely,
>> Gour
>>
>> --
>> From anger, complete delusion
>> arises, and from delusion
>> bewilderment of memory. When memory is
>> bewildered,
>> intelligence is lost, and when intelligence is lost
>> one falls
>> down again into the material pool.
>>
>>
>>
>>
>>
>>
>>
>

Re: [Pharo-users] Is possible to keep some code closed in Pharo?

[Dimitris Chloupis]

If you make a morph maximise and pin it down, it will cover the entire
pharo windows and wont be movable and will make it impossible for the user
to interact with the IDE even via shorcuts. If I am wrong on shortcuts I
hope someone correct me but last time I checked that was the case.

Command line wise, command line api is very elegant, very simple to add and
remove arguments.

Those will block the user from controlling Pharo.

Soruce code visibility:

1) What stef said, delte sources
2) If you use monticello the traditional way ,it saves in mcz files which
are jus zip files with source code files inside. Created every time you
save to a local or remote repo
3) Delete any fileouts, those produce st files too, smalltalk source code
files
4) if you use filetree that uses source files too but generally you would
pick a directory outside pharo
5) changes files also contain source code you modified or added
6) We hava new recovery tool, I forget the name, has its own file format I
dont rememebr if it uses text files like changes, it might, check that out
too.

Generally anywhere you spot a file with st extension its a source code
file, delete it or move it away. We may use an image format but we generate
a ton of source code files for various reason as you can see.

On Fri, Oct 13, 2017 at 8:27 PM Ricardo Pacheco <
ricardo.pacheco.rol...@gmail.com> wrote:

> Wow, that sounds great. Thanks a lot!!
>
> Ricardo
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[Dimitris Chloupis]

Well oh Well, Python is stupid Very, very stupid

To my suprise live coding in Python its actually easier to what I expected
and almost the same, from user perspective to that of pharo.Minus the IDE
conveiniece of course.  But a pain in the hat to find the proper way to do
it.

I was reloading modules, was thining of implementing become to python ,
which basically means replacing references to old instance object with
references to new objects , then I thought that it would be more efficient
to just reference the new methods to the instances and after a TON of
testing I realized this is dead simple and for some reason python hides it
very well. All the above were completely unecessary.

Insance methods are referencing functions in the class object. Apparently
functions in a class are taken as class methods and functions with self as
first argument are considered instance methods. Which means I just copy
paste the code of the method to the debugger, and assign it back to the
existing live class and all instances are updated automagically. No need
for become, no need to update instances manually no need to even reload the
module. Similarly you can delete methods and add methods on the fly always
live. Renaming a method is basically deleting and assigning . Renaming the
class is the same. As is for class and instance variables. So anything can
change on the fly. Names are there for your pleasure, in the end all that
matters are the references.Its objects all the way down.

The equivelant of a python instance method defiition and live updae , the
python way, on Pharo would be

MyClass instanceMethodName:= myMessage firstArg:self arg2: foo1 arg3:
foo2
|locals|
code stuff

and you python "call it" or message it

MyClass insanceMethodName arg2:foo1 arg3: foo2 , no need to use self when
calling it. Self is automatically passed because from the definition python
knows this is suppose to be an insance method.

or you could put a block after the assigment , because the name of the
message is assigned by the assignment anyway,  for class method you ommit
the first argument of self. Calling is the same. This replaces a method or
adds it if does not exist. All instances of that live class are immediately
poitining to the new method. So the class is basically a collection of
references.

So all I have to do now is to wrap the copy paste and assignment in a
single shortcut or button and I am ready to fly to live coding land. Days
wasted chasing my tail but at least I learned a lot about python objects
which are basically dictionaries objects (for variables) plus function
objects (for class and instance methods) wrap inside an object, or rather
referenced, called a class.

Storing the live state , similar to fuel, is supported by the pickle
library.

Why on earth python made it so hard something so simple to understand ? no
idea .I dont even need to make a live coding enviroment library as I
assumed, its already there, hiding under the cover too scared to come out.


Now I know why none or almost none does live coding in Python.

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

[Dimitris Chloupis]

Modularisation is coming whether you like it or not
its called

Bootstrap

And the more modular the image will get the more will get closer to
namespaces anyway. So frankly all I have to do is wait and if I can of
course contribute ;)

You can call it Bootstrap or the Pink Elephant for all I care, in the end
for me its about having multi layer system. That's all I care.

But you wont get an argument from me the more about the fact that the more
we wait the harder will get but again, I am not a Bootstrap contributor so
I have no right to complain. I really admire those people :D

Modularisation for personal project is super easy to do,if you do it from
the start that is,  its the existing code that is a pain in the hat to
modularise when until fairly recently even colors were hard coded into the
IDE.

On Fri, Oct 13, 2017 at 3:55 PM Esteban A. Maringolo 
wrote:

> 2017-10-13 5:55 GMT-03:00 Norbert Hartl :
> >
> >> Am 13.10.2017 um 10:24 schrieb stephan :
> >>
> >> On 13-10-17 09:55, Thierry Goubier wrote:
> >>> Because namespaces, by essence, come with serious issues. I won't take
> >>> someone seriously on namespaces until he can cite those faithfully.
> >>
> >> Let's start with the misconception that namespaces are about
> modularisation
> >>
> > +1
>
> +1 to this as well.
>
> Having modularization is like having security, very hard to add them
> later if you didn't include it in the original design.
>
> I'm using VisualWorks these days, and I find its namespaces something
> more of a hassle than a real use.
>
> If we could name Classes with a dot, that could solve most of what
> namespaces are used for in practice: avoiding name colissions.
> That's why most of the popular frameworks have prefixes like Zn, WA,
> RB, and so on and so forth. But now I'm used to prefixes, I don't need
> them. :)
>
> Modularity is a different beast, if you look at how some modules work
> in JS, like AMD, you see that in practice they avoid collisions by
> importin what they need from a module, and assign it to a "namespace"
> (it is not, but works as such), so they get modules first, and
> namespacing later.
>
> Regards,
>
> Esteban.
>
>

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

[Dimitris Chloupis]

I am against the very idea of special syntax. Even python uses special
syntax as nothing more than syntactic sugar to make the code more readable
from the point of view of not everything looking the same. I agree with the
concept of everything being an Object.

I also dont like the idea that we tend to not have a clear cut border
between the IDE and the language/library. Of course I think IDE
functionality as much as namespaces is concerned (within the borders of my
understanding) is essential. But should be seperate and the IDE act mostly
as a visualisation tool and automation tool.

My problem , is that the Pharo operates on a global space , so lets say i
do what I said above I still dont avoid name collisions. Because MyInstance
outside MyModule should diffirent from MyInstance inside MyModule.

It could become possible by masking the names from the user.

So that there is no conflict between

MyModule MyInstance
and
MyModule2 MyInstance

unless you introduce of couse similar to python the optional feature of
collapsing the scope.

We already have Packages which tie in with Metacello, so I was think about
Modules or however we want to call them as a layer between. I am fine with
metacello personally. Its the name collisions that only concerns me and not
forcing me to use unique names. Of course a module can contain other
modules.

I know how to do this for my projects , I would manipulate the IDE into
displaying Modules as a seperate row in System Browswer , Packages will
continue being the the up most container. And for name of a class I would
add the name of the Module to the class , if I wanted to keep supporting
the existing enviroment , but hack it so it appears to the user as 2
seperate things

so for user will see

MyModule MyInsance myMessage:

 but it  Would be for the system
MyModuleMyInstance myMessage:

which would make sense from naming persepctive even to an outsider not
using the module system and would not require for him to install the modue
library
and essentially

MyModule MyInstance
act as you said via Message not understood as a reference to
MyModuleMyInstance . A unary message returning a reference to an instance
or class or other object.

of course you will have a class like ModuleGenerator to handle the
technical details for you

Version control , dependencies and other technicallities would be handled
normally as usually by Metacello with MyModule pointing also to the correct
configuration , baseline, whatever.

At least thats my general idea of it.

On Fri, Oct 13, 2017 at 2:16 PM Thierry Goubier <thierry.goub...@gmail.com>
wrote:

> Hi Kilon,
>
> then the discussion is a bit different. As your example points out, the
> syntax is already there, but the notion of a module is still open and ties
> into the package management.
>
> I've played a bit with Metacello to have a working "project" concept
> synchronized with Metacello, and I could imagine providing module like
> objects (the baseline itself?) giving access to more generic names instead
> of the internal, prefixed ones.
>
> One suggestion maybe: what about trying it for yourself with one of your
> projects? With a kind of overall class which has the name of the module,
> and automatically adding methods to it (or a #doesNotUnderstand: that
> handles those) for all the classes in the module, removing from the class
> name the prefix? It would allow an experiment, to see how the code looks
> like and if it is understandable, or if a special syntax is necessary.
>
> Thierry
>
>
> 2017-10-13 11:51 GMT+02:00 Dimitris Chloupis <kilon.al...@gmail.com>:
>
>> to be more specific what I mean because apparently I may know nothing
>> about namespaces , I was talking in terms of Python's module and package
>> system
>>
>> even though python uses special syntax "import" to import a module, a
>> source file, the real functionality is actually a method but of an object
>> dealing with the handling of modules and packages , packages are basically
>> file directories containing mutliple modules
>>
>> as soon as you do the import the syntax is the usual object syntax
>>
>> so
>>
>> Dog.bark()
>>
>> can be anything
>> 1) A class method call, Dog being the class
>> 2) A instance method call, Dog being the instance
>> 3) or a function call, Dog being the function , which is also an object
>> (methods in python are basically function object taking the reference to an
>> instance as first argument, hence why the weird syntax of adding self as
>> first argument when we define instance method) and Dog is the module
>> imported.
>>
>> of course in case (3) you can collapse the module "name" so you can do
>> only bark() if you import via "from Dog import *" which means fro

Re: [Pharo-users] Pillar (was Re: Behold Pharo: The Modern Smalltalk)

[Dimitris Chloupis]

Why exporting to latex, html and markdown is not enough for you ?

On Fri, Oct 13, 2017 at 1:05 PM Gour <g...@atmarama.com> wrote:

> On Wed, 11 Oct 2017 17:18:54 +
> Dimitris Chloupis <kilon.al...@gmail.com>
> wrote:
>
> > Well there is a move towards Pillar for class and method commands so
> > who knows maybe we will have that soon enough ;)
>
> Let me say that I'm very happy seeing that Pillar is moving forward (e.g.
> addition of support for footnotes) as well as plan for the future (*.epub
> support) since I'm considering whether it could serve as single-source
> markup
> for all of one's writings?
>
> After migrating from Python-powered static-site-generator (to Hugo) and rst
> markup I was considering to use AsciiDoc(tor) markup for all my content,
> but,
> so far, due to using Emacsm settled to use org-mode instead. Haven't tried
> with
> slides (yet), but there is Pandoc support for it.
>
> Therefore, I'd rather see Pillar support in Pandoc which would buy us even
> more
> import/export capabilities for free instead of focusing on single formats
> like
> *.odt, *.epub etc.
>
> Pillar with 1st class support in Pandoc would, imho, improve status of
> Pharo
> itself making it along with Pillar exceelent tool for development as well
> as
> for all writing needs - articles, books, documentation,
> slide-presentations.
>
> But it would be nice to make it more transparent where/how can one submit
> feature request for Pillar?
>
> Fogbugs issue trakcer is certainly not the ideal place these days...
>
>
> Sincerely,
> Gour
>
> --
> Everyone is forced to act helplessly according to the qualities
> he has acquired from the modes of material nature; therefore no
> one can refrain from doing something, not even for a moment.
>
>
>
>

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

[Dimitris Chloupis]

to be more specific what I mean because apparently I may know nothing about
namespaces , I was talking in terms of Python's module and package system

even though python uses special syntax "import" to import a module, a
source file, the real functionality is actually a method but of an object
dealing with the handling of modules and packages , packages are basically
file directories containing mutliple modules

as soon as you do the import the syntax is the usual object syntax

so

Dog.bark()

can be anything
1) A class method call, Dog being the class
2) A instance method call, Dog being the instance
3) or a function call, Dog being the function , which is also an object
(methods in python are basically function object taking the reference to an
instance as first argument, hence why the weird syntax of adding self as
first argument when we define instance method) and Dog is the module
imported.

of course in case (3) you can collapse the module "name" so you can do only
bark() if you import via "from Dog import *" which means from module Dog
import every object.
But from import is frown upon in the python world because obviously it
makes it easier to have name collision which is what the module system try
to avoid in the first place.

So the equivelant of pharo would be

MyModule MyInstance myMessage:

or if you include packages as well

MyPackage MyModule MyInstance myMessage:

which follows pharo syntax and OO design. That's my general idea at least.

Please enlighten me :)

On Fri, Oct 13, 2017 at 12:30 PM Dimitris Chloupis <kilon.al...@gmail.com>
wrote:

> On Fri, Oct 13, 2017 at 11:31 AM Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
>
>> 2017-10-13 10:12 GMT+02:00 Dimitris Chloupis <kilon.al...@gmail.com>:
>>
>>> fair enough you think namespaces are not the right solution, what you
>>> think is the right solution then ?
>>>
>>
>> I told you. Namespaces are a solution, but they come with issues.
>>
>>
>
> Then I misunderstood you but I am geniouly interested in what those
> problems are and I think the infromation is something others will find
> interesting as well.
>
> No. In the HPC world, a common held position is that Fortran code is 30%
>> faster than C++.
>>
>
> Cannot even rememeber the last time a 3d graphics developers mentioned
> Fortran.I occasional frequent forums and mailing lists plus keeping in
> contact with Blender developers.
>
> I have heard that Fortran can outperform C++ in numeric computation around
> the percentage you mentioned but first time I heard that its generally
> faster.
>
> Language Benchmark seems to strongly disagree
>
> http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ifc=gpp
>
> of its widely criticized but then what benchmark is not
>
>
>> Remember that part of my job is to write compilers.
>>
>>
> I knew that you write compilers (SmaCC) I did not realise you are a pro
> and especially on ones that generate highly optimised machine code
>
>
>> I'm also consider a guy to talk to when someone has deep issues with some
>> of the new features of C++... even if I don't do C++, I can often reframe
>> what the feature means in the overall scheme of programming languages.
>>
>
> On other hand I have close to zero experience on compilers
>  .
>
>
>> I find it very interesting. I consider that current compilers are very
>> good optimising code that is written in a language that obscures the
>> developper intent in the first place.
>>
>
> I lost you there, you mean compilers for other languages than C++ ?
>
> As I told you, I work in a world where performance is paramount and C++ is
>> strongly criticized for the fact its incidental complexity makes it very
>> very hard to reach or maintain performance levels (compared to Fortran,
>> say).
>>
>> Thierry
>>
>>
>
> And I "work" in a world that C++ is the undisputed king , that's 3d
> graphics , though I must admit I try to stick with Python as much as I can.
>
> In any case my point was that if namespaces can be done in a badly design
> language , should be possible in Pharo and easier. Not ease, just easier.
>
> Of course that's just a wild assumption but I hope this thread do not only
> disaprove my assumption but said a light in the real challanges of
> namespace implementation
>
>

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

[Dimitris Chloupis]

On Fri, Oct 13, 2017 at 11:31 AM Thierry Goubier <thierry.goub...@gmail.com>
wrote:

> 2017-10-13 10:12 GMT+02:00 Dimitris Chloupis <kilon.al...@gmail.com>:
>
>> fair enough you think namespaces are not the right solution, what you
>> think is the right solution then ?
>>
>
> I told you. Namespaces are a solution, but they come with issues.
>
>

Then I misunderstood you but I am geniouly interested in what those
problems are and I think the infromation is something others will find
interesting as well.

No. In the HPC world, a common held position is that Fortran code is 30%
> faster than C++.
>

Cannot even rememeber the last time a 3d graphics developers mentioned
Fortran.I occasional frequent forums and mailing lists plus keeping in
contact with Blender developers.

I have heard that Fortran can outperform C++ in numeric computation around
the percentage you mentioned but first time I heard that its generally
faster.

Language Benchmark seems to strongly disagree

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ifc=gpp

of its widely criticized but then what benchmark is not


> Remember that part of my job is to write compilers.
>
>
I knew that you write compilers (SmaCC) I did not realise you are a pro and
especially on ones that generate highly optimised machine code


> I'm also consider a guy to talk to when someone has deep issues with some
> of the new features of C++... even if I don't do C++, I can often reframe
> what the feature means in the overall scheme of programming languages.
>

On other hand I have close to zero experience on compilers
 .


> I find it very interesting. I consider that current compilers are very
> good optimising code that is written in a language that obscures the
> developper intent in the first place.
>

I lost you there, you mean compilers for other languages than C++ ?

As I told you, I work in a world where performance is paramount and C++ is
> strongly criticized for the fact its incidental complexity makes it very
> very hard to reach or maintain performance levels (compared to Fortran,
> say).
>
> Thierry
>
>

And I "work" in a world that C++ is the undisputed king , that's 3d
graphics , though I must admit I try to stick with Python as much as I can.

In any case my point was that if namespaces can be done in a badly design
language , should be possible in Pharo and easier. Not ease, just easier.

Of course that's just a wild assumption but I hope this thread do not only
disaprove my assumption but said a light in the real challanges of
namespace implementation

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

[Dimitris Chloupis]

"Let's start with the misconception that namespaces are about modularisation

Stephan "

  Well I can only for speak for Python because is where I used  namespaces
the most and the language I am most experienced with. Namespaces in python
are merely objects that come with a collection of method speciallised in
the handling of source code files , individuals and in collection with all
the objects contained in them , cause everything in python apart from the
core synstax are object.

Last time I checked, objects even in Pharo are abour modularistation so it
stands to reason that at least in Python namespaces are too.

Maybe your refer to something else ?

Re: [Pharo-users] "Building-With versus Building-on"

[Dimitris Chloupis]

What is a VA Java ? and a VA C++ ?

Call me an idiot or insane but I am in favor of combiding languages, though
I only have heard of COBRA never used it.

I am a lawyer by profession, I know fellow lawyers still using DOS and
QBasic databases and yes under windows .. sadly very common for
businesses here. Ah the pleasures of technology but nothing comes close to
the pleasure of rejecting it.

On Fri, Oct 13, 2017 at 12:49 AM Andrew Glynn <aglyn...@gmail.com> wrote:

> I know about personalization being a lot of work, particularly with
> Eclipse.  I copied the text out of the ‘summary’ page in About Eclipse into
> Kate, and it was 1233 lines long, lol.
>
>
>
> I was one of two team leads on what was probably the most complex
> application I’ve worked on, using VA Java and VA C++ with CORBA to exchange
> objects (the need to combine both was due to legacy issues).  Siemens now
> owns the application, which was successful enough to bankrupt its closest
> competitor, but the binary jars in the latest version are still dated 2002,
> and every addition has been made via .the WS* API we included, which if I
> remember correctly, uses version 1.x of WebSphere.  I’m a bit surprised it
> still runs at all tbh, but its security must be horrible by now.
>
>
>
> Eclipse’s only saving grace is EMF/CDO, and a few projects built on them,
> IMHO.
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Dimitris Chloupis <kilon.al...@gmail.com>
> *Sent: *Thursday, October 12, 2017 2:05 PM
> *To: *Any question about pharo is welcome <pharo-users@lists.pharo.org>
> *Subject: *Re: [Pharo-users] "Building-With versus Building-on"
>
>
>
> It's a mentality issue, modern programming languages provide the material
> necessary to create innovative environments but their communities just
> simply does not care. A language designer may introduce a feature in a
> language that is super useful. Still people may not use it.
>
>
>
> And let's face it even with Pharo nothing beats a personalized
> environment, of course personalisation is a lot of work. Hence why people
> avoid it.
>
>
>
> Essentially boiling down to cooking your own food instead of getting it
> from a shop. When you begin to learn how to cook , its kinda sucks, but the
> more you cook the better it tastes. Of course it takes time to get there
> and hence why so few people cook.
>
>
>
> Eclispe , which I will disagree with your that is not the worst IDE,
> started as a smalltalk IDE and then it got Eclipsed. I am sure those people
> had a "build on" environment , still it got messy. We can blame porting to
> Java, but can we really blame Java for the mess that is called
> "Eclipse" e nope.
>
>
>
> I once saw a youtube video about a musician using windows sounds (the
> standard sounds we all know of) to make  a very nice music piece. He did
> all that using multiple instances of windows media player. Just pause
> reading think about this for a minute. That's the real essence of creativity
>
>
>
> Use something very limited and come up with something amazing. The
> software industry is not about creativity for the most part. On the other
> hand I that work with 3d its amazing how fast super cool new technologies
> pop around like mushrooms. Every year we have massive improvements in
> libraries and tools. But the coding for 3d graphics is all about creativity
> , artists are not very forgiving for ugly GUI, limited features and
> innovation stagnation. Artists want to be inspired by the tools they use.
> But then that's the creativity realm. Creativity pays the bills in this
> case, lack of it , game is not fun, rendering or animation is not fun, you
> can lose millions.
>
>
>
> Of course in the creativity realm , there is too much innovation and
> unless you keep up you are kicked out the door, yesterday. Which brings
> down to the problem of complexity and how you deal with it. And I don't
> mean about bad complexity , aka web dev, I am talking about good
> complexity. Features you cannot ignore because other will use before you
> and you are left behind etc.
>
>
>
>
>
> On Thu, Oct 12, 2017 at 7:13 PM Peter Fisk <peter.f...@gmail.com> wrote:
>
> Thanks for posting this.
>
>
>
> It is one of the best descriptions of the state of the software industry
> that I have seen.
>
>
>
>
>
> On Thu, Oct 12, 2017 at 11:50 AM, Andrew Glynn <aglyn...@gmail.com> wrote:
>
> https://medium.com/@dasein42/building-with-versus-building-on-c51aa3034c71
>
>
>
> This is an article not *specifically* about Pharo, rather on the state of the 
> industry
> in general and how it got that way, but positing Pharo as a way to learn
> building-*on* rather than building-*with*, where in the latter case on
> every project you start at essentially the same place.
>
>
>
> As a result it does put in front of people a fair amount of info on Pharo,
> and challenges them to try it.
>
>
>
> cheers
>
> Andrew Glynn
>
>
>
>
>

Re: [Pharo-users] FYI about Pharo MOOC

[Dimitris Chloupis]

I could help with the Greek subtitles but I am fundamental against the idea
of learning anything code wise in a non english language. It does much more
damage than good. Congrats for making it so accessible and all your hard
work :)

On Fri, Oct 13, 2017 at 9:42 AM Gour  wrote:

> On Thu, 12 Oct 2017 21:59:53 +0200
> Stephane Ducasse
>  wrote:
>
> > I'm about to release the en versions.
> > you can find them unofficially on http://www.stephaneducasse.eu/MOOC/
>
> I've downloaded one and can I safelyassume that the 'new' videos are same
> content as the old ones jsut with the English voice dubbed over?
>
> In that case, I'd prefer to use/watch old ones with the subtitles.
>
>
> Sincerely,
> Gour
>
> --
> He who is satisfied with gain which comes of its own accord, who
> is free from duality and does not envy, who is steady in both
> success and failure, is never entangled, although performing actions.
>
>
>
>

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

[Dimitris Chloupis]

Personally I dont get it, we find the path to bootstrap the pharo image
clear and we cannot see the path to namespaces ?

it makes zero sense to me

Plus what you say, countless and countless of implementation of namespaces
out there. And again what you say about perfection.

If C++ can improve, If C++ can dream of namespaces planning the
introduction of modules(in future version) in replacement (not removal) of
his awful header file format I think we got the excuse to be confident
we can come up with something decent.

We develop a freaking IDE for crying out loud.

No it wont be a walk in the park, no it wont get done in one or next
version, and no it cannot be an individual our outside effort. But we have
the community super qualified to do it.

On Fri, Oct 13, 2017 at 8:51 AM Ben Coman  wrote:

> On Thu, Oct 12, 2017 at 8:52 PM, Sean P. DeNigris 
> wrote:
>
>> horrido wrote
>> > Having separate namespaces would be really good.
>> > VisualWorks has them. Why not Pharo?
>>
>> I can't remember ever hearing disagreement on this subject. It seems the
>> only questions have been: 1) how to do them *right*,
>
>
> The default position would be leveraging someone else's experience, so
> this begs the question, what is wrong in namespace implementations in VW,
> Gemstone, Squeak (as our immediate neighbours, then plus Dolphin,
> SmalltalkX, other languages)
> Are there been any research papers around comparing these?
>
> I found the "Pharo on Gemstone VM" talk impressive.  The "develop on Pharo
> deploy on Gemstone" philosophy seems like a nice synergy for Pharo's
> commercial future.  So a naive approach would be to do namespaces just like
> Gemstone.  Maybe its not the best, but would it be "good enough" --
> perfection being the enemy of done and all that jazz.
>
> cheers -ben
>
>
>> and 2) where they fall on the endless prioritized todo list
>>
>

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[Dimitris Chloupis]

> That is a familiar path, but still an obstacle for people to get over in
> trying Pharo - i.e. its a barrier of entry.  I've previously referred to
> this article by JoelOnSoftware, but to pull out a key part... "Think of
> these barriers as an obstacle course that people have to run before you can
> count them as your customers. If you start out with a field of 1000
> runners, about half of them will trip on the tires; half of the survivors
> won’t be strong enough to jump the wall; half of those survivors will fall
> off the rope ladder into the mud, and so on, until only 1 or 2 people
> actually overcome all the hurdles. With 8 or 9 barriers, everybody will
> have one non-negotiable deal killer.  This calculus means that eliminating
> barriers to switching is the most important thing you have to do if you
> want to take over an existing market, because eliminating just one barrier
> will likely double your sales. Eliminate two barriers, and you’ll double
> your sales again."
>
>

WARNING LONG POST AHEAD

There numerous reason why this kind of thinking is fundamental flawed, if
not completely wrong

1) How you get people to run in this race ?
2) What makes you think that people participating in the race doing to get
first or even finish ?
3) How you are certain that those barriers are not the very reason people
participate ?

The fundamental problem is that if you base your assumption that people are
motivated on avoidance of pain, this is a very popular argument by the way,
you going to be severely disapointed. From the very first fact that there
is a 90% chance that right now that you use almost 100% of your time one of
the worst software to be ever created.

Microsoft Windows.

Of course you can throw claims to me that peope use Windows because that is
what's popular and widely available, but then so is MacOS is by far the
easiest to use OS out there. When you pit Windows vs Macos a such taboo
subject , fuel to so many flame wars, there is one thing that both sides
agree on and that is that MacOS is far easier to use , perdiod. The rest of
the debate which OS is the best is up in the air and frankly not the point
of my argument.

The fact is , we love pain, we love barriers, we love doors that slam into
our face. We love challange. But only if we find it interesting.

Of course Windows is not the only example  (C/C++ , Java , Web dev,
computer games and the list is just endless)of the machocistic nature of
human beings. I dont need to look far, my own story about how I started
coding is more than enough . I am going to ramble about my initiation to
the realm of coding , so feel free to ignore the rest of my post but what
the hell here we go.

>From an early age , no idea when, I was exposed to the idea of the
computer. Never used one before or saw on in person other than what I saw
in the TV I asked my father to get me one and he agreed on the ground that
I wont use it just to play games but to learn how to code. My father had no
idea what coding is, had no idea what technology is, to this day he hates
technology and he refuses to learn even how to close a window. None ,
friend , relative or random stranger I knew used a computer.

So I got this weird thing called computer and turned it on, of course
motivated to play games like any other kind in my age, I was 9 years old at
the time, december 1988. But I had a sense of honor even from that age so I
had to keep my promise. So I did and I was fascinated by it, to the degree
that I was coding as much I was playing games. Problem is that it was
mainly masochistic venture. I had one book and one book alone, none that
had any clue how to show how to turn this thing on and of course no
internet, no schools, no magazines I could afford to buy or even know where
to buy them . So in 3 years, I made nothing special, only tiny fragments of
code and I was still struggling with basic concept like looping.

Yes, looping.

 But I already was doing things that a greek kid did not suppose to do and
I did not even fit the geek stereotype at the time (not that the term
existed at the time, I still does not exist in my language), I had tons of
friends, I was anything but shy , I was the craziest nosiest kid suffering
from the annoying syndrom of hyperactivity and with very lmited attention
span.

I was the absolute worst candidate to learn how to code, yet I did . Sort
of. Then my father decided to send me, after me begging on my knees, on a
prrivate school, that just opened near our neighborhood for learning. At
the time time I only still had the same computer, Amstrad CPC 6128 and knew
the very basics of Locomotive Basic which was used also by the computer as
a bash like language for its OS.

I went 3 years, the first year I did ok, an average student even though I
had by far the most experience than other kids we learned GWBASIC. The
second year I did terrible, we learned DBASE and the third we learned
CLIPPER and blow any other student completely away, I 

Re: [Pharo-users] "Building-With versus Building-on"

[Dimitris Chloupis]

It's a mentality issue, modern programming languages provide the material
necessary to create innovative environments but their communities just
simply does not care. A language designer may introduce a feature in a
language that is super useful. Still people may not use it.

And let's face it even with Pharo nothing beats a personalized environment,
of course personalisation is a lot of work. Hence why people avoid it.

Essentially boiling down to cooking your own food instead of getting it
from a shop. When you begin to learn how to cook , its kinda sucks, but the
more you cook the better it tastes. Of course it takes time to get there
and hence why so few people cook.

Eclispe , which I will disagree with your that is not the worst IDE,
started as a smalltalk IDE and then it got Eclipsed. I am sure those people
had a "build on" environment , still it got messy. We can blame porting to
Java, but can we really blame Java for the mess that is called
"Eclipse" e nope.

I once saw a youtube video about a musician using windows sounds (the
standard sounds we all know of) to make  a very nice music piece. He did
all that using multiple instances of windows media player. Just pause
reading think about this for a minute. That's the real essence of creativity

Use something very limited and come up with something amazing. The software
industry is not about creativity for the most part. On the other hand I
that work with 3d its amazing how fast super cool new technologies pop
around like mushrooms. Every year we have massive improvements in libraries
and tools. But the coding for 3d graphics is all about creativity , artists
are not very forgiving for ugly GUI, limited features and innovation
stagnation. Artists want to be inspired by the tools they use. But then
that's the creativity realm. Creativity pays the bills in this case, lack
of it , game is not fun, rendering or animation is not fun, you can lose
millions.

Of course in the creativity realm , there is too much innovation and unless
you keep up you are kicked out the door, yesterday. Which brings down to
the problem of complexity and how you deal with it. And I don't mean about
bad complexity , aka web dev, I am talking about good complexity. Features
you cannot ignore because other will use before you and you are left behind
etc.


On Thu, Oct 12, 2017 at 7:13 PM Peter Fisk  wrote:

> Thanks for posting this.
>
> It is one of the best descriptions of the state of the software industry
> that I have seen.
>
>
> On Thu, Oct 12, 2017 at 11:50 AM, Andrew Glynn  wrote:
>
>> https://medium.com/@dasein42/building-with-versus-building-on-c51aa3034c71
>>
>>
>> This is an article not *specifically* about Pharo, rather on the state of 
>> the industry
>> in general and how it got that way, but positing Pharo as a way to learn
>> building-*on* rather than building-*with*, where in the latter case on
>> every project you start at essentially the same place.
>>
>>
>> As a result it does put in front of people a fair amount of info on
>> Pharo, and challenges them to try it.
>>
>>
>> cheers
>>
>> Andrew Glynn
>>
>>
>