Re: [Pharo-dev] [Pharo-Launcher] call for tests on Windows

[philippe.b...@highoctane.be]

I guess that it is what I installed and it works fine on my Win 10 system.

Nice icon BTW.

Now there is an issue with the mouse pointer in the launcher and all pther
images (so maybe a VM problem).

The cursor is all black and tiny and has no white surroundings. In a dark
theme the cursor is close to invisible.

Also the cursor is not obeying the magnification setting of Windows. It
worked before.


I guess that the cursor masks are  not applied properly + other new stuff.

That is ruining the whole Pharo experience for me (and I guess newcomers).


Phil

On Mon, Apr 16, 2018, 16:14 Christophe Demarey 
wrote:

> Hi,
>
> Regarding the various problems Pharo Launchers had on Windows, we worked
> on a new installer based on Advanced Installer [1] to avoid UAC (User
> Account Control) and write permissions problems. This new installer now
> installs Pharo Launcher in the user’s local app data folder (where for
> sure, he has write permissions). Pharo Launcher also now have its own icon
> and use its own name instead of Pharo. Also, the uninstaller now works as
> expected. Last but not least, the installer is now signed to avoid warning
> of Windows Defender.
> Thanks to Ben Coman who did the first version of the packaging using
> Advanced Installer (was NSIS).
> This version should also improve the launch of Pharo images on Windows.
>
> So, please could you install and test this new version: and report any
> problem with it? http://files.pharo.org/pharo-launcher/win-alpha/
> We do not have windows users around so it’s hard to know if it works
> outside our tests boxes.
>
> Thanks,
> Christophe
>
> [1] https://www.advancedinstaller.com/
>

Re: [Pharo-dev] [ANN] New Pharo 6.1 version

[philippe.b...@highoctane.be]

sounds very interesting!

Phil

On Thu, Apr 5, 2018, 15:01 Esteban Lorenzano  wrote:

> https://pharo.fogbugz.com/f/cases/20944/Integrate-Epicea-8-2-8-in-Ph6-1
>
>
>

Re: [Pharo-dev] [ANN] Cruiser: A Pharo app packager

[philippe.b...@highoctane.be]

Vincent,

When it comes to UnifiedFFI what would be your advice to have it working?

I am using quite a few such calls.

Thx for this cool tool, I'll try it out this week end for sure!

Phil

On Thu, Mar 8, 2018, 20:30  wrote:

> Hi Pharoers!
>
> I pleased to announce you the first release of Cruiser: a tool to package
> your Pharo applications. The idea is to quickly convert an application from
> a development environment to a production one. A production environment
> means:
>
>   *   No writing on the disk
>   *   No access to the source code (by the shortcuts, debugger,...)
>   *   No error displaying on the interface
>   *   The only thing accessible is the user application
>
> I let you discover it on: https://github.com/VincentBlondeau/Cruiser
>
> [cid:image002.png@01D3B6D0.B0BAA0B0]
>
> Do not hesitate to ask me questions or contribute to improve it!
>
> Cheers,
>
> Vincent Blondeau
> Software Engineer, Software and Controls | Global Product Group
> Desk +1 510.572.7499
>
> Lam Research Corporation
> 4650 Cushing Pkwy, Fremont, CA 94538 USA | www.lamresearch.com
> Connect with Lam Research: Facebook<
> https://www.facebook.com/LamResearchCorporation> | Twitter<
> https://twitter.com/lamresearch> | LinkedIn<
> https://www.linkedin.com/company/lam-research>
>
> 
>
> NOTICE: This e-mail transmission may contain confidential information. If
> you are not the intended recipient, or a person responsible for delivering
> it to the intended recipient, you are hereby notified that any disclosure,
> copying, distribution or use of any of the information contained in or
> attached to this message is STRICTLY PROHIBITED. If you have received this
> transmission in error, please immediately notify the sender and destroy the
> original transmission and its attachments without reading them or saving
> them to disk. Thank you.
>

Re: [Pharo-dev] Change Pharo window icon

[philippe.b...@highoctane.be]

Well, Windows is still Windows at the core.

Even some Windows 2.0 books can provide insights into its working
principles that are hard to find these days.

Anyway, I remember that there is a way to change the icon at runtime but
not when listing the exe. Hence Resource editor.

Phil

On Feb 2, 2018 21:17, "Stephane Ducasse"  wrote:

> Yes I did that when I was at University. So clearly dated.
>
>
> On Fri, Feb 2, 2018 at 8:40 PM, p...@highoctane.be 
> wrote:
> > For Windows one can change it using a resource editor.
> >
> > http://www.angusj.com/resourcehacker/
> >
> > Phil
> >
> > On Feb 2, 2018 20:33, "Stephane Ducasse" 
> wrote:
> >>
> >> Would it be possible to change the icon without having to compile a new
> >> VM?
> >> To me the current setup looks so monolithic and dated.
> >> I would expect that somebody can deploy a application with its own
> >> logo by just providing some new resources.
> >>
> >> Stef
> >>
> >> On Wed, Jan 31, 2018 at 11:17 PM, Eliot Miranda <
> eliot.mira...@gmail.com>
> >> wrote:
> >> > Hi Vincent,
> >> >
> >> > On Wed, Jan 31, 2018 at 12:07 PM, 
> >> > wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> I would like to know how to change the main Pharo window icon. I saw
> >> >> that
> >> >> there is a primitive for the title:
> >> >> DisplayScreen class  >> primitiveWindowTitle:string: ; primitive:
> >> >> 'primitiveHostWindowTitle' module:'HostWindowPlugin'
> >> >> but I cannot find one for the icon.
> >> >> Should another primitive need to be implemented?
> >> >
> >> >
> >> > The icon is baked into the VM executable.  So to change it one has to
> >> > build
> >> > a VM with a different icon.
> >> >
> >> > On Windows it is in
> >> > {build.win32x86,build.win64x64}/pharo.cog.spur/Pharo.ico
> >> > and the file that specifies to use Pharo.ico is
> >> > {build.win32x86,build.win64x64}/pharo.cog.spur/Pharo.rc
> >> >
> >> > On Mac OS X it is in
> >> > platforms/iOS/vm/OSX/Pharo.icns
> >> > (alongside three others such as PharoImage.icns)
> >> > and the file that specifies to use Pharo.icns is
> >> > {build.macos32x86,build.macos64x64}/pharo.cog.spur/Makefile
> >> > in setting the VM variable.  The file that associates the other icons
> >> > with
> >> > specific file types is
> >> > platforms/iOS//vm/OSX/Pharo-Info.plist
> >> >
> >> > If you're changing the Pharo icon let me suggest you update the icon
> >> > files
> >> > themselves in the opensmalltalk-vm source tree.
> >> >
> >> > If you're creating a new variant of the VM for some new purpose (say a
> >> > special Lam VM) then let me suggest you add the icons to the
> >> > opensmalltalk-vm source tree, creating special build directories for
> >> > these
> >> > VMs, such as {build.macos32x86,build.macos64x64}/lam.pharo.cog.spur/
> >> >
> >> > If you want to do this privately, then take either of the approaches
> >> > above
> >> > and simply don't publish the edits.  You can write a script that takes
> >> > an
> >> > updated checked-out opensmalltalk-vm source tree and edits it with
> files
> >> > from a specific repository.  I have such scripts and can help you with
> >> > them.
> >> > Hint, pax is a very convenient directory hierarchy copying tool
> >> > available at
> >> > least on Mac OS X.  pax -rwlk will copy the trees under a sequence of
> >> > directories into their corresponding places in a target tree.
> >> >
> >> >>
> >> >> Thanks!
> >> >>
> >> >> Vincent
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > _,,,^..^,,,_
> >> > best, Eliot
> >>
> >
>
>

Re: [Pharo-dev] [ANN] Next Pharo release moved to end of year

[philippe.b...@highoctane.be]

Sounds like a realistic plan.
Good to read that.

I have the impression that Pharo 3, Pharo 5, Pharo 7 will be the solid
releases.

Are we having a pattern here?

Phil

On Jan 23, 2018 14:20, "Esteban Lorenzano"  wrote:

Hi all,

After some analysis of current condition of development, we decided to move
the upcoming release to end of the year (and not May, as usual).
The reason is that we are taking more time than expected to finish/polish a
quantity of things that needs to be finish to call this a “successful
release” to make us feel confortable with a release early this year.

Thing is… we were very ambitious with this version, because a lot of small
pieces get into position and we decided to act.
Now, to deliver a good version, we need to finish them.

For example, along with all the stabilisation phase we need to operate on
P7 (an usual task for every version), we still need to finish this
important changes:

- fullblocks as default
- vm 64bits: stabilise and add win64
- stateful traits
- calypso (and nautilus removal)
- iceberg: fix the UI

We (the core team and the community) have a deep commitment with the
progress of Pharo, and we will continue get things right to make the
continue improvement a pleasant experience.

Say that, expect new announcement of things finished and ready to test next
weeks :)

cheers!
Esteban

Re: [Pharo-dev] [ANN] Next Pharo release moved to end of year

[philippe.b...@highoctane.be]

Sounds like a realistic plan.
Good to read that.

I have the impression that Pharo 3, Pharo 5, Pharo 7 will be the solid
releases.

Are we having a pattern here?

Phil



On Jan 23, 2018 14:20, "Esteban Lorenzano"  wrote:

> Hi all,
>
> After some analysis of current condition of development, we decided to
> move the upcoming release to end of the year (and not May, as usual).
> The reason is that we are taking more time than expected to finish/polish
> a quantity of things that needs to be finish to call this a “successful
> release” to make us feel confortable with a release early this year.
>
> Thing is… we were very ambitious with this version, because a lot of small
> pieces get into position and we decided to act.
> Now, to deliver a good version, we need to finish them.
>
> For example, along with all the stabilisation phase we need to operate on
> P7 (an usual task for every version), we still need to finish this
> important changes:
>
> - fullblocks as default
> - vm 64bits: stabilise and add win64
> - stateful traits
> - calypso (and nautilus removal)
> - iceberg: fix the UI
>
> We (the core team and the community) have a deep commitment with the
> progress of Pharo, and we will continue get things right to make the
> continue improvement a pleasant experience.
>
> Say that, expect new announcement of things finished and ready to test
> next weeks :)
>
> cheers!
> Esteban
>

Re: [Pharo-dev] New Year Wishlist (2018) ?

[philippe.b...@highoctane.be]

On Dec 29, 2017 02:48, "Pierce Ng"  wrote:

On Wed, Dec 27, 2017 at 04:41:56PM +0100, Cyril Ferlicot D. wrote:
> I also forgot: a real headless :)

And real "embeddability". :-) I'll write GUIs with Pascal/Lazarus if I must.


That would actually suit me very well too.

Being able to implement domain logic stuff in Pharo embedded into the
application will super charge productivity.


+1 million

Phil


Pierce

Re: [Pharo-dev] Advent of code

[philippe.b...@highoctane.be]

I made an adventofcode channel in Discord. Time for bots...

Phil

On Nov 22, 2017 21:25, "Stephane Ducasse"  wrote:

> Ok can you put a link on the advent of code web page?
>
> On Wed, Nov 22, 2017 at 9:11 PM, Julien 
> wrote:
>
>> I’ll write a README with some instructions to avoid clash when merging
>> pull requests.
>>
>> For example, each participant could create a directory with its name and
>> put all his stuff inside it.
>>
>> Julien
>>
>> Le 22 nov. 2017 à 21:09, Stephane Ducasse  a
>> écrit :
>>
>> Tx I forked it.
>>
>> On Wed, Nov 22, 2017 at 5:38 PM, Julien 
>> wrote:
>>
>>> Ok I created one [1], maybe if multiple people are playing with me we
>>> can gather the different solutions we get for each puzzle in this
>>> repository.
>>>
>>> Julien
>>>
>>> [1]: https://github.com/juliendelplanque/AdventOfCode2017WithPharo
>>>
>>> Le 22 nov. 2017 à 16:55, Stephane Ducasse  a
>>> écrit :
>>>
>>> Julien
>>>
>>> could you open a github project so that we can do the same as norviq?
>>> And get a log of the problems and solution?
>>>
>>> Stef
>>>
>>> On Wed, Nov 22, 2017 at 2:25 PM, Serge Stinckwich <
>>> serge.stinckw...@gmail.com> wrote:
>>>
 BTW, the Japanese Smalltalk community is doing an advent Calendar every
 year:

 https://qiita.com/advent-calendar/2016/smalltalk

 The 2017 edition is in preparation here: https://qiita.com/advent-calen
 dar/2017/smalltalk



 On Wed, Nov 22, 2017 at 1:29 PM, Stephane Ducasse <
 stepharo.s...@gmail.com> wrote:

> Hi pharoers
>
> I would like to know if you would like to participate to
> http://adventofcode.com/2016
>
> For example we could do the same as
> https://github.com/norvig/pytudes/blob/master/ipynb/Advent%2
> 0of%20Code.ipynb
>
> Stef
>
>


 --
 Serge Stinckwich
 UMI UMMISCO 209 (IRD/UPMC/UY1)
 "Programs must be written for people to read, and only incidentally for
 machines to execute."http://www.doesnotunderstand.org/

>>>
>>>
>>>
>>
>>
>

Re: [Pharo-dev] Alternative window manager

[philippe.b...@highoctane.be]

I need to give it some love as the keybindings are all acting bad.
Aerosnap style stuff to be added as well.

There is an issue with integrating the world menu due to morphic changes.
Do I disabled it.

I'll give it a shot for 6.1 as  it is now a 5
0 thing.
Phil

On Nov 10, 2017 22:36, "Alistair Grant"  wrote:

> Hi Thomas,
>
> On 10 November 2017 at 11:46, Thomas Dupriez
>  wrote:
> > Hello,
> >
> > Does an alternative window manager for pharo exist?
> >
> > For some reasons I always end up with a tangled mess of windows when
> using
> > the default one. My biggest gripe is that new windows tend to open on
> top of
> > other windows, blocking the view even if there is still empty space
> > elsewhere.
> >
> > I watched this video ( https://www.youtube.com/watch?v=Wx0eNaGzAZU )
> about
> > the i3 window manager for linux and how it paves the screen with the
> windows
> > to optimise screen space and make things look less messy, and was
> wondering
> > whether something like that existed for pharo.
> >
> > Cheers,
> > Thomas
>
> Have you looked at Tiling Window Manager?  It doesn't solve the
> problem of windows opening on top of each other, but makes it easy to
> position them:
>
> Metacello new
> baseline: 'TilingWindowManager';
> repository: 'github://Pharophile/TilingWindowManager:master/packages';
> load.
>
>
> If there's another window manager that is similar to i3 or Awesome I'd
> love to hear about it. :-)
>
>
> Cheers,
> Alistair
>
>

Re: [Pharo-dev] TechTalk today, 17h UTC "Free talk Pharo 7"

[philippe.b...@highoctane.be]

Having a kind of demo on how to get started in contributing to 7.0 from
scratch would be nice.

Another thing that interests me is theme support with palettes etc.

Phil

On Sep 19, 2017 11:26, "Esteban Lorenzano"  wrote:

> Hi,
>
> Today we have the montly TechTalk at 17hs UTC.
> x
> So far, I think this is something I would like to talk:
>
> - new development process status
> - tonel 1.0/iceberg 0.6 status
>
> but… subject is “free talk” so prepare your questions/opinions :)
>
> Esteban
>

Re: [Pharo-dev] Esteban's ChangeLog week of 21 August 2017

[philippe.b...@highoctane.be]

On Aug 28, 2017 6:11 PM, "Sean P. DeNigris"  wrote:

EstebanLM wrote
> This is my weekly ChangeLog, from 21 August 2017 to 27 August 2017.

Thank you for all the work you consistently do, especially the stuff deep
down in the system which brings no personal glory but provides the
foundation for the creations of our entire community!


I beg to differ as what is done there is actually glorious and deeply
appreciated from where I do stand.

Esteban, Master of Code (level: 10K).

Phil




-
Cheers,
Sean
--
View this message in context: http://forum.world.st/Esteban-
s-ChangeLog-week-of-21-August-2017-tp4964905p4965162.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] [Ann] PharmIDE is renamed to TelePharo and moved to github

[philippe.b...@highoctane.be]

Well I would just subclass the TlpRemoteIDE class with the other name and
delegate a connectToRemote: to connect:

Indeed there is material that would be better kept in line with the current
code.

I was demoed another approach to remote master/slave debugging at VUB this
week and they were using Seamless + TaskIt2 (so there is actully a remote
taskit worker implementation) + debug stack fuel.

I recommended using Beacon as well.

Interesting times!

Phil


On Aug 23, 2017 13:29, "Denis Kudriashov"  wrote:

> 2017-08-23 12:21 GMT+02:00 p...@highoctane.be :
>
>> Hey Denis,
>>
>> That's a decent name. At least this is settled.
>>
>> Now code that reads:
>>
>> remotePharo := TlpRemoteIDE connectTo: ()
>>
>> is annoying with the "Remote" because it somewhat implies that the IDE is
>> remote.
>> But the IDE is local and connects to a remote.
>>
>> Maybe
>>
>> remotePharo := TlpIDE connectToRemote: (...)
>>
>> is more intention revealing.
>>
>
> Good point. But I made many videos where I show this name. So I don't want
> to rename it in nearly future.
> Maybe with auto deprecation of classes it can be not a problem. I want add
> it in Pharo 7.
>
>
>>
>> A question: is it possible to connect an image to itself?
>>
>> Like in
>>
>> remotePharo := TlpIDE connectToLocal.
>>
>> Could have interesting side effects :-)
>>
>
> Theoretically it can work. But right now debugger is not working is that
> case. Errors lead to hanging image due to infinite recursion where remote
> debugger requests local debugger which is remote debugger itself.
> I don't think it is a practical case.
>
>
>>
>> Best,
>> Phil
>>
>>
>>
>> On Wed, Aug 23, 2017 at 10:52 AM, Denis Kudriashov 
>> wrote:
>>
>>> Hi.
>>>
>>> In the team we finally agreed on the end name for project. It is now
>>> TelePharo.
>>> Prefix "tele" means some action on or by distance. And this is what the
>>> project is about: to work remotely with Pharo images.
>>> Not all people like this name. But there are no name which was good for
>>> everybody. So it was decision. And we now continue with it.
>>>
>>> With new name project was moved to github repository
>>> https://github.com/dionisiydk/TelePharo with all dependencies. Feel
>>> free to fork and report bugs.
>>>
>>> You can find more details in my blog http://dionisiydk.blogspot.fr/
>>> 2017/08/pharmide-is-renamed-to-telepharo-and.html.
>>>
>>> Best regards,
>>> Denis
>>>
>>
>>
>

Re: [Pharo-dev] @About posting here

[philippe.b...@highoctane.be]

Because it works.

Because GMail is able to make sense of all threads/groupings on a mobile
phone.

Because of GMail search is awesome on email.

Because one can check what is going on in the community quitr fast that way.

Discord being cool for more direct interaction.

Now, why is it you seem to complain about this or that in about every
thread?

Content looks like interesting but tone comes across as pretty conflictual.
That makes me  just label you as a bore and not care about anything, which
is contrary to your apparent intent.

Lots of people on this list are in the industry for decades and have
shipped product on various scales.

TL;DR please behave.

Phil




On Aug 15, 2017 22:11, "Frank-B"  wrote:

> @about this forum at world.st
>
> I have a lot of forum experience from studying "forum psychology and
> sociology" in three different language and in various forums run by very
> different software but I have never come about any system that is *nearly
> as
> crappy, sick and idiotic as this one here*:
>
> - various message don't show up here
> - masses of emails that I am not interested in are polluting my email
> client
> (and I will stop this silly downloading tonight by directing them straight
> into the delete folder)
> - and one is never informed if there is any reply to one's posting, which
> is
> standard on almost all forums and comment part of blogs
> - and there is no chance to directly reply to some post
> - thus there is no branching of the subjects
> - which makes following a sib-thread most difficult
>
> I am neither going to write answers in my email clent, not will I continue
> to pollute my system with 99% unwanted messages.
>
> I just ask myself: Why are Smalltalk people with the "best" IDE of all
> using
> such a crappy system!?
>
> Mailing lists are something - in my view - s much outdated and just a
> pain in the!
>
> Now: Hunt me, shout at me, call me whatever you want! That's fine by me. It
> would be the normal reaction of a crowd if a new sheep dares to criticise
> what the crowd has been doing for long. I don't care!
>
> Regards
> Frank
>
>
>
>
> --
> View this message in context: http://forum.world.st/Anybody-
> using-Orca-Smalltalk-to-JavaScript-tp4960519p4961497.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] [IMPORTANT] Following changes in the bootstrapping process

[philippe.b...@highoctane.be]

Massive.

What is in the super small image?
Is Hermes going to be a generic binary content loader?

Phil

On Aug 1, 2017 12:36, "Stephane Ducasse"  wrote:

> Hi Pavel
>
> This is super excellent! IMPRESSIVE. An image without the compiler and
> a reloadable compiler.
> Super cool.
>
> Stef
>
>
> On Tue, Aug 1, 2017 at 11:57 AM, Pavel Krivanek
>  wrote:
> > Hello,
> >
> > we are checking a huge pull request #177
> > (https://github.com/pharo-project/pharo/pull/177) that will change some
> > basics of the bootstrap process:
> >
> > Now we will bootstrap a smaller image that will not include
> compiler/parser.
> > Compiler and related packages are exported and loaded using a binary
> > exporter named Hermes.
> > The compiler is then used to load FileSystem and Monticello. The rest of
> the
> > bootstrap process will be the same as before.
> > As the result we will have faster bootstrap and better system
> modularization
> > and possibilities.
> >
> > It required some modularization efforts:
> >
> > - simplified initialization scripts
> > - Use Zinc converters and encoders instead of FilePathEncoder and old
> > TextConverter
> > - Use Stdio instead of FileStream
> > - Using File instead of FileSystem
> > - Deprecated FileStream & childs (Moved to Deprecated70)
> > - Extracted Path classes to their on package: FileSystem-Path
> > - Moved OpalEncoders to their own package. They are required by the
> runtime
> > (not only for compilation)
> > - Introduced AsciiCharset in the kernel to answer to #isLetter
> #isUppercase
> > and so on without requiring full Unicode tables from the beginning
> > - Cleaning up a bit the full exception logging infrastructure (streams,
> > transcript, files, stack printing...)
> > - Split Ring methods required for system navigation to the
> Ring-Navigation
> > package
> > - Remove usages of #translated in the kernel
> > - Refactored the bootstrapping classes to remove duplications
> > - Cleaning up dependencies in CompiledMethod>>printOn:
> > - fix path printing
> >
> > We need to merge these changes at once and of course it can cause some
> > conflicts with the existing pull requests or external code. Anyway, we
> need
> > to merge it as soon as possible.
> >
> > So please, try to look at the PR and test the resultant image [1] to
> avoid
> > some major problems.
> >
> > [1]
> > https://ci.inria.fr/pharo/view/7.0/job/70-PR-Check-Load/
> lastSuccessfulBuild/artifact/bootstrap-cache/Pharo7.0-32bit-9c0691d.zip
> >
> > Cheers,
> > -- Pavel
> >
>
>

Re: [Pharo-dev] CPU and RAM usage of Pharo3 vs. Pharo6

[philippe.b...@highoctane.be]

There is a server mode option somewhere that could reduce some usage.

Maybe it will help.

Phil

Le 9 juin 2017 13:07, "Holger Freyther"  a écrit :

> Hey!
>
> my current major deployment is still with Pharo3 and due some bigger
> changes I start to migrate to Pharo6 and today I finally managed to update
> the test deployment (and be happy with it). The test is not scientific but
> maybe an early indicator that there is something to look at?
>
> The image is idle and not handling any application payload so it might be
> a fair comparison because of that.
>
> RSS + ~16 MiB RAM (~53 Mib vs. ~69 Mib)
> CPU + ~0.005s per real second passed (think of Amazon AWS why that could
> matter)
> (In ~1400s wall clock  57.8s vs. 50.86s cpu time was used)
>
> Does anyone else see this increased usage? Has anyone explored the source
> of it? Does anyone of you share the concern I have? :)
>
> holger
>
>
>
> Outline of the setup:
>
> * Take a Pharo3 or Pharo6 base image
> * Load my code (and its dependencies, big difference is version of Voyage)
> * Start the images on the test system
> * Opens a TCP connection, initialize VoyageMongo
> * Wait for work
>
> Look at top for RSS and CPU time used.
>

Re: [Pharo-dev] remote development via VS Code

[philippe.b...@highoctane.be]

We need to open this up..
I want to expose the image using fuse on linux.
Holidays coming...

Phil

Le 8 juin 2017 10:17, "Dimitris Chloupis"  a écrit :

> problem is when you try to use a generic ide or an ide made for another
> language is that you get a sub standard experience. For example pyDev is an
> Eclipse extension that allows one to use Eclipse which is a predominantly
> Java IDE for Python. I used that in the past now I use PyCharm a Python
> exclusive IDE that is like nigh and day with PyDev.
>
> Pharo IDE has a lot of issues (auto completion being the worst for me) but
> its after all tailor made for Pharo. IDE APIs by the way are very common ,
> especially for open source IDEs like Eclipse, Netbeans etc. So its possible
> to connect pharo with a ton of IDEs out there and not particularly hard ,
> but there is little motivation to do so.
>
> On Thu, Jun 8, 2017 at 8:19 AM Ben Coman  wrote:
>
>> I just bumped into Microsoft's MIT Licensed IDE "Visual Studio Code" that
>> runs on OSX, Linux & Windows.  What is interesting is their Debug Protocol
>> for connecting to language specific debuggers.
>> * https://code.visualstudio.com/docs/extensionAPI/api-debugging
>>
>> If I had time, it would be interesting (and super cool) to build a Debug
>> Adaptor in Pharo
>> * https://code.visualstudio.com/docs/extensionAPI/language-support
>> as well as a Language Server Protocol provider
>> * https://code.visualstudio.com/docs/extensionAPI/language-support
>> Could make a good student project or two.  The skills learnt and
>> demonstrated would be quite marketable outside of the Pharo community.
>>
>> From a marketing perspective, it might be more palatable for existing
>> Visual Studio users to install Pharo as an extension rather than install
>> Pharo as a whole new IDE (i.e. Pharo) - a common complaint about Smalltalk
>> in general.  At a minimum there is the exposure gained from Microsoft's
>> Extension Marketplace, with early adoptors trying out Pharo
>> just-because-its-there. It also smashes that regular criticism of Smalltalk
>> that it lives too much in its on isolated world.
>>
>> It might attract developers wanting to do polygot development, for
>> example (just guessing that might be possible):
>> * game development using Unity libraries for the game engine with
>> Ronnie's minimal-vm embedded as the scripting language,  and debugging both
>> in parallel from a single environment
>> * Pharo web server backend with Javascript frontend
>>
>> I vaguely wonder if it would be possible to make a Debug Adaptor that
>> integrates VM & Image level debugging, transparently stepping from
>> Smalltalk into the VM C code.  That could be useful for FFI debugging, or
>> developing low-level graphics interfaces that might break our internal IDE.
>>
>> Disclaimer: Like all my random ideas, its a bit vague and dreamy, but I
>> had no concept of it yesterday, so just sharing the find to stimulate
>> future ideas.
>>
>> cheers -ben
>>
>

Re: [Pharo-dev] Release deferred to next Tuesday :(

[philippe.b...@highoctane.be]

Please use https://pharo.fogbugz.com/f/cases/20101 for this effort. Load
the slice first as I made a pass already.

Phil

Le 1 juin 2017 19:49, "Ben Coman"  a écrit :

>
>
> On Thu, Jun 1, 2017 at 9:27 PM, Esteban Lorenzano 
> wrote:
>
>> Hi list,
>>
>> yes, this release is being a pain.
>> anyway, yesterday after asking for testI found two blocking issues and
>> one “nice to have” and I needed to work on them.
>> Blocking issues were:
>>
>> 1) Athens (with Fonts ) was not working on 64bits and because of that,
>> Roassal was not either.
>> 2) There is a problem in VM packaging which packages as files what should
>> be symlinks.\
>>
>> The nice to have:
>>
>> It seems there are english problems in the welcome browser (and in the
>> STAGE pages). It would be nice if some native speaker takes a look :)
>>
>
> I'll do this tomorrow.
> cheers -ben
>
>
>>
>> I already fixed (1) and I’m working on (2), but the release is deferred
>> to Tuesday because: a) we want to test. b) you never release on friday c)
>> monday is holiday here :)
>>
>> So well, that.
>>
>> I’m sorry.
>>
>> Esteban
>>
>>
>>
>>
>>
>

Re: [Pharo-dev] [Vm-dev] multiple crashes on macOS Sierra

[philippe.b...@highoctane.be]

I got that too (windows).

And that's also one reason  why I made this thing.

https://github.com/Pharophile/HOImageSaver

I am actually running under a VM I built because that one is not
mysteriously crashing and as I have an assert and debug version, I hope to
find the reason why this happens.

Yes it sucks the joy out.

Phil

Le 28 mai 2017 10:41, "Tudor Girba"  a écrit :

> Hi,
>
> I just had the issue again while typing code.
>
> I actually cannot work. Is it really only me, or is it that others just
> got used to living with this and not report the issue?
>
> I would consider this a blocker. Do you agree?
>
> Cheers,
> Doru
>
>
> > On May 26, 2017, at 8:10 AM, Tudor Girba  wrote:
> >
> > Hi Nicolas,
> >
> > Thanks.
> >
> > You might be right. It just happened again while typing.
> >
> > I am using:
> > - Pharo image: 60497
> > - VM:
> > CoInterpreter VMMaker.oscog-eem.2203 uuid: 
> > 12d4afae-8498-4e76-8efe-60eba6ef4db2
> May  2 2017
> > StackToRegisterMappingCogit VMMaker.oscog-eem.2203 uuid:
> 12d4afae-8498-4e76-8efe-60eba6ef4db2 May  2 2017
> > VM: 201705021552 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> $ Date: Tue May 2 08:52:41 2017 -0700 $ Plugins: 201705021552
> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
> >
> >
> > 
> >
> > Cheers,
> > Doru
> >
> >
> >> On May 25, 2017, at 4:44 PM, Nicolas Cellier  gmail.com> wrote:
> >>
> >> Hi Tudor,
> >> it seems you type too fast.
> >> More seriously, if I google some of the apple methods in the stack like
> for example
> >> "bug InputMethodInstanceProcessEventRef_WithCompletionHandler"
> >> I see quite some many hits indicating that:
> >> - we are not alone
> >> - either there are some bug on mac os
> >> - or it's complex to use the frameworks right...
> >>
> >> Debugging this kind of low level problem is going to be tough...
> >> Probably some advanced objective-C knowledge is required.
> >>
> >> 2017-05-24 22:28 GMT+02:00 Tudor Girba :
> >>
> >> Hi,
> >>
> >> Today I experienced multiple crashes on macOS Sierra.
> >>
> >> These happened during regular programming, mostly while typing code. I
> attached here the crash dump(s). I believe I heard Phil having the same
> issue with the stable Pharo VM.
> >>
> >> Does anyone else has the same issue?
> >>
> >> The VM is:
> >> CoInterpreter VMMaker.oscog-eem.2203 uuid: 
> >> 12d4afae-8498-4e76-8efe-60eba6ef4db2
> May  2 2017
> >> StackToRegisterMappingCogit VMMaker.oscog-eem.2203 uuid:
> 12d4afae-8498-4e76-8efe-60eba6ef4db2 May  2 2017
> >> VM: 201705021552 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> $ Date: Tue May 2 08:52:41 2017 -0700 $ Plugins: 201705021552
> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
> >>
> >> The Pharo update number is: 60482
> >>
> >> Cheers,
> >> Doru
> >>
> >> --
> >> www.tudorgirba.com
> >> www.feenk.com
> >>
> >> "From an abstract enough point of view, any two things are similar."
> >>
> >>
> >>
> >>
> >>
> >
> > --
> > www.tudorgirba.com
> > www.feenk.com
> >
> > "If you interrupt the barber while he is cutting your hair,
> > you will end up with a messy haircut."
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Being happy is a matter of choice."
>
>
>
>
>
>

Re: [Pharo-dev] FileTree/Iceberg and SSDs, change the file format

[philippe.b...@highoctane.be]

There is the same kind of issues with Hadoop but the block size is 128MB.
So, lots of small files give the same issue.

This is solved by having HAR files (Hadoop Archive) that contain the files.

The haddop filesystem is usually able to access the har contents somewhat
transparently from userland.

But I guess that libgit will not be too cooperative.

We can also look into how to mount such an archive as a filesystem.


Phil



Le 21 mai 2017 17:27, "Stephan Eggermont"  a écrit :

At the PharoDays I was painfully reminded that SSDs perform really badly
when using small files. The Bloc tutorial used a github filetree repo and
that has a lot of files. The whole folder is 116 MB in 16K files. Copying
that amount of data should not be noticable, taking about a third of a
second. With it being in so many files, it took more than half a minute, or
a hundred times as long.

That is too much overhead. How can we improve the file format in a way that
keeps the cross-platform exchange advantages and a reasonable way to view
diffs and propose small changes using the github web tools?

Cuis uses a different format with git. How does that compare? What is used
in Squeak?

Stephan

Re: [Pharo-dev] [Moose-dev] [ann] bloc & cairo+morphic

[philippe.b...@highoctane.be]

Definitely great!

It is nice to see feenk getting more Pharo solid engineering super powers.

Phil

Le 8 mai 2017 23:00, "Tudor Girba"  a écrit :

> Hi,
>
> We are happy to announce that based on the work of Glenn, Alex extended
> Bloc (Sparta) to work directly in the Morphic world using Cairo as a
> backend.
>
> Cairo is less powerful than Moz2D (see the screenshot below for an
> example), but the implementation addresses a concern that the community
> raised regarding a perceived increased liability due to the dependency to
> Moz2D. Essentially this means that Bloc can be treated as another graphical
> library that can coexist with Morphic without requiring any external VM
> plugin.
>
>
> I would also like to point out that adding a new backend and host was
> possible because of the many iterations (including throwing away whole
> implementations) that Alex and Glenn went through. I think they did an
> amazing job.
>
> You can find a bit more details about Bloc here:
> http://www.humane-assessment.com/blog/bloc-flexible-backends-hosts/
>
> Another issue raised regarding Bloc was that of the engineering effort
> required to make it a reality. That is why I would also like to announce
> that Alex joined feenk.com where he is primarily working on the graphical
> stack for Pharo.
>
> Cheers,
> Doru
>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "To lead is not to demand things, it is to make them happen."
>
>
>
>
>
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
>

Re: [Pharo-dev] Tired of losing messages after 10k. Can we re-discuss moving Slack community to Discord?

[philippe.b...@highoctane.be]

We just invited gsoc students and we have the mentors channel running and
then we shit things down.

Lame.

Phil

Le 7 avr. 2017 15:06, "Norbert Hartl"  a écrit :

> If enough people move and there is a note the others will follow
>
> Norbert
>
> Am 07.04.2017 um 14:39 schrieb Alexandre Bergel :
>
> I would not mind moving to Discord. But, what is the plan to kill Slack?
> Can a Slack project be simply removed?
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> On Apr 7, 2017, at 8:59 AM, Esteban Lorenzano  wrote:
>
> Hi,
>
> That.
> I’m also willing to try another service if you find something better, but
> I find discord cool enough.
> Some remarks:
>
> - I actually like Slack. The problem is the amount of information lost
> because they do not display more than 10k lines (or we pay, and is super
> expensive).
> - No, plain #irc is not an option. Community has talked… and it does not
> works… I have had more productive talks in one month in Slack than 5 years
> trying #irc.
>
> cheers!
> Esteban
>
>
>
>
>

Re: [Pharo-dev] PharoSpur32Vm

[philippe.b...@highoctane.be]

I made my own build here.
Not up to date with latest stuff but should work for the build process.

https://ci.appveyor.com/project/philippeback/pharo-vm

It uses my forked repo and provided you set your own bintray env vars for
API keys will publish there.

Check all of the output of env vars and where/which in the appveyor console
to see what gets used when when it comes to compilers and so on as there
were various compiler versions involved at one point.

Third party cache part is also worth checking.

Still not able to build on my local box at the moment due to some tools
discrepancies happening.

My build artifacts are embarking too much at this point but allow you ro
get the release, debug, and assert vms for windows. This helps when
debugging as backtraces and so on are much more meaningful and one can use
gdb more effectively to understand what is going on.

Just keep the dlls and exes and you'll be fine.

HTH

Phil

Le 15 mars 2017 08:58, "Nicolai Hess"  a écrit :

>
>
> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier  gmail.com>:
>
>>
>>
>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier > l.com>:
>>
>>>
>>>
>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess :
>>>


 2017-03-11 10:01 GMT+01:00 Nicolas Cellier <
 nicolas.cellier.aka.n...@gmail.com>:

> Hi Nicolai,
>
> If you look at appveyor.yml configuration on
> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.
> appveyor.yml, you will see that the pharo brand is not yet in the
> matrix.
>
> It's because builds are based on cygwin, but as I understood, some
> library used by some plugin required by pharo refuse to compile with
> cygwin. They appear to work with mingw32.
> Cygwin provides headers for legacy directx, some distribution of
> mingw32 did in the past, but it does not seem the case anymore.
> Using the directx headers from Microsoft SDK is a problem. They are
> not redistributable and can't be found anymore on the net (too old). We
> cannot seriously base the builds on something so fragile (both technically
> and legally) in the long term.
>
> Also, the 64 bits VM does only work with clang, and we don't have
> anything available as a 64bits Microsoft SDK... So pharo has to fix that
> too.
>
> In the interim, you should look at https://github.com/pharo-proje
> ct/pharo-vm/blob/master/.appveyor.yml and follow the scripts there.
>

 Ok, thank you.


>>>
>>> I gave it a shot on sunday, because it was particularly rainy in Nantes,
>>> and I almost succeeded in compiling all the dependencies with cygwin.
>>> Well, I mean with autotools cmake libtool pkg-config and I surely forget
>>> a few other niceties that some not so well informed programmers committed
>>> with the faith that it would make their life "easier". It certainly does
>>> not make mine simpler...
>>> Almost, because gcc 5.4.0 failed to compile cairo with ssize_t: it seems
>>> that the workaround of Igor does not work anymore.
>>> ssize_t, WTF???
>>> Maybe I'll be able to fix it tonight. Or tomorrow. In which case I'll
>>> publish the branch to see how far appveyor goes.
>>>
>>>
>>>
>>
>> So I solved the ssize_t problem by removing the hack from Igor which is
>> not necessary anymore...
>> But got another problem soon after while building the tests...
>> There are trailing lines generated at end of
>> tests/cairo-test-constructors.c that make the compilation fail:
>>
>> i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I..  -I. -I./pdiff
>> -I../boilerplate -I../util/cairo-missing -I../util/cairo-script -I../src
>> -I../src -D_REENTRANT -I/cygdrive/y/Smalltalk/opensm
>> alltalk-vm/.thirdparty-cache/windows/i386/include/pixman-1
>> -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/
>> windows/i386/include/libpng16 -Wall -Wextra -Wmissing-declarations
>> -Werror-implicit-function-declaration -Wpointer-arith -Wwrite-strings
>> -Wsign-compare -Wpacked -Wswitch-enum -Wmissing-format-attribute
>> -Wvolatile-register-var -Wstrict-aliasing=2 -Winit-self
>> -Wunsafe-loop-optimizations -Wno-missing-field-initializers
>> -Wno-unused-parameter -Wno-attributes -Wno-long-long -Winline
>> -fno-strict-aliasing -fno-common -Wp,-D_FORTIFY_SOURCE=2
>> -Wno-unused-but-set-variable  -D_REENTRANT  -m32
>> -static-libgcc -static-libstdc++ -I/cygdrive/y/Smalltalk/opensm
>> alltalk-vm/.thirdparty-cache/windows/i386/include -march=pentium4 -c -o
>> cairo_test_suite-cairo-test-constructors.o `test -f
>> 'cairo-test-constructors.c' || echo './'`cairo-test-constructors.c
>> cairo-test-constructors.c:1118:1: attention : la définition de données
>> n'a pas de type ni de classe de stockage
>>  oning ();
>>  ^
>> cairo-test-constructors.c:1118:1: attention : type defaults to ‘int’ in
>> declaration of ‘oning’ [-Wimplicit-int]
>> 

Re: [Pharo-dev] Growing large images: the case of Moose models

[philippe.b...@highoctane.be]

Le 3 mars 2017 13:56, "Clément Bera"  a écrit :



On Fri, Mar 3, 2017 at 12:12 PM, Cyril Ferlicot D.  wrote:

> On 03/03/2017 11:56, Clément Bera wrote:
> > Hello everyone,
> >
> > This morning I investigated with Vincent Blondeau a problem reported by
> > the Moose community a while ago: loading Moose model is slower in Spur
> > (Pharo 5+) than in pre-Spur (Pharo 4 and older). In general, this
> > problem was present for anyone growing images to a significant size.
> >
> > To investigate the problem, we loaded a 200Mb[3] Moose model on a 250Mb
> > image, growing the image to 450Mb. Loading such a model takes 2 minutes
> > in Spur and 1m30s in pre-Spur VMs.
> >
> > Using the stable Pharo VM, the analysis results were the following:
> > - total time spent to load the Model: 2 minutes
> > - time spent in full GC: 1 minute (4 fullGCs)
> > - time spent in scavenges[1]: 15 seconds
> > On the 2 minutes spent, we have 50% of the time spent in full GCs, 12.5%
> > in scavenges, 37.5% executing code.
> >
> > We then used the latest VM that features the new compactor (VM from
> > beginning of March 2017 and over). The full GC execution time went down
> > from 1 minute to 2 seconds.
> >
> > In addition, we increased the size of Eden[2] from 4Mb to 12Mb. Time
> > spent in scavenges decreased from 15 seconds to 5 seconds.
> >
> > Overall, loading the model is now taking ~50 seconds instead of 2
> minutes.
> >
> > To increase Eden size, one needs to run a script similar to:
> >
> > | currentEdenSize desiredEdenSize |
> > currentEdenSize := Smalltalk vm parameterAt: 44.
> > desiredEdenSize := currentEdenSize * 4.
> > Smalltalk vm parameterAt: 45 put: desiredEdenSize.
> >
> > _*And then restart the image.*_
> >
> > I hope this report can be useful for some of you. I will try to make a
> > blog post out of it, detailing other GC settings one can change from the
> > image to improve performance.
> > _*
> > *_
> > Best,
> >
> > Clement
> >
> > [1] A scavenge is basically the garbage collection of only young objects
> > [2] Eden is basically the space where objects are initially allocated.
> > [3] All numbers in the report are order of magnitudes and not precise
> > numbers
> >
> >
> >
>
> Hi,
>
> This is great! We will probably try it soon on our models.
>
> Guillaume had a question also, what is the counterparty if we let the
> EdenSize at this size when we are not loading/exporting a MSE?
>

There are 2 main counterparts:
- You waste a bit of memory. If you increase from 4Mb to 12Mb, you waste
8Mb.
- The user-pauses for scavenges may be more significant.

There are customers using 64Mb Eden in production. It improves their
performance, they do not care about wasting 60Mb on machine with 16Gb RAM
and their application does heavy computation and does not need to be that
responsive.

However for UI applications (typically the IDE), the scavenge pauses may
become significant enough to be noticed by the programmer. Maybe not at
12Mb, but certainly at 64Mb.

For your case:
- Do you care that your application use some more Mb of RAM ?
- Do you care if your application takes a couple extra ms to answer a
request ? (In any case, the full GC takes much more time and also delays
the answer right now)
If you don't care, you can use larger Eden. In any case, an Eden of 12 or
16 Mb should be safe.

There are other settings that can be useful in your case. I will try to
write a post about it.


> Because in our case we deploy a server that might need to read some MSE.
> We cannot restart it with our current solution. In that case it would be
> good to have more info to select the best EdenSize for the server.
>
> Thank you!
>

I have images that do not shrink with the new compactor and as there are no
leaks I am wondering if there is a way for me to diagnose why this happens.
I am routinely loading 100MB XML in the image but these are only transient.
Shrinking works with a Pharo6 image but not with a 5.0 based. Strange.
Anyone willing to pair over the internet to have a look?
It is annoying because I am providing those images to customers and an ever
growing thing is not really great especially with a non standard tech I am
trying to push forward there.

Phil


> --
> Cyril Ferlicot
>
> http://www.synectique.eu
>
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
>
>

Re: [Pharo-dev] Slack, fragmentation and design information

[philippe.b...@highoctane.be]

I miss the Squeak wiki Pharo style.

Phil

Le 10 févr. 2017 19:06, "Esteban A. Maringolo"  a
écrit :

> 2017-02-10 14:59 GMT-03:00 p...@highoctane.be :
> > Mass adoption and hyper reduced friction to get people on board.
> >
> > For me: I have 10+ slack teams in my slack client and there is really no
> > point in having more clients on the desktop.
>
> +1 to this. This is key.
>
> Maybe what we're missing is a simple wiki to collect the shared
> knowledge, recipes, and other stuff.
>
>
> Esteban A. Maringolo
>
>

Re: [Pharo-dev] Why are issue priority automatically changed from 3 to 5 ?

[philippe.b...@highoctane.be]

+100
Priority has nothing to do with the release per se.

Phil

Le 31 janv. 2017 00:11, "Nicolai Hess"  a écrit :

>
>
> 2017-01-30 15:23 GMT+01:00 Pavel Krivanek :
>
>> Hi Nicolai,
>>
>> I'm checking all current issues marked for Pharo 6 and testing if they
>> are new or the problem already existed in Pharo 5. According to it I'm
>> marking it and for most cases (but not all) I'm decreasing the priority to
>> "Fix if Time".
>> I understand you but look at the priorities as priorities for the
>> releasing process. Of course a lot such issues should be fixed and if you
>> think they must be fixed for the upcoming release, increase the priority.
>> Currently the assignment of priorities is on issue reporters and they use
>> different personal scales. This way we can unify that a little bit.
>>
>> After finishing of the marking I wanted to ask people to think again
>> about priorities of the reported issues. But If we already made a release
>> with some issue, it probably means it is not extremely important.
>>
>
> I am not talking about "extremely important" issues. If it is an issue
> that "must be fixed for this release", I would use the "show stopper"
> priority.
> Now if some uses used his time to report an issue, say one as priority
> "fix if time" and another one "must fix", now we put all this issues to
> "fix if time", don't you think we loose some valuable information ?
> If this issues won't be fixed in this release (because we don't have
> enough man power) we can always put them on "Later" instead of "Pharo 6.0"
> For me, it makes a difference if some issues occure in some situations,
> where we can maybe work around, and can be fixed "if time" or if an issues
> is a bug
> that must be fixed just because the functionality is just not working
> anymore.
>
>
>>
>> This step needs to be done anyway or we will never finish the release. To
>> do it now gives us more time to focus on really important things. We want
>> every new release to be better that release before so it makes sense to
>> firstly look at new problems we created.
>>
>
> I don't get this point. Some issues were just introduced in the pharo 5.0.
> So instead of seeing this issues as "must fix", we decrease the priority as
> "fix if time", so we can focus on the issues we introduced in Pharo 6.0?
>
>
>
>> Cheers,
>> -- Pavel
>>
>>
>> 2017-01-30 14:07 GMT+01:00 Nicolai Hess :
>>
>>> For example:
>>> 19457
>>> 
>>> Scrolling Versionner configuration list is very slow
>>> 18778
>>> 
>>> FileList "View as" does not work
>>> 19221
>>> 
>>> Rub Find And Replace can not search for "?"
>>>
>>> For me, these are issues that "must fix" and not "Fix If Time". Most
>>> issues are only
>>> fixed "if someone has the time to do it" regardless how serious they are.
>>> Fixed if time looks like , we can live without this as we did since the
>>> last
>>> release, but actually we are just used to accept some bugs and
>>> regressions because
>>> we know we are to small or to few develoeper to actually fix this issues.
>>> I don't see any value in downgrading the priority - else we could just
>>> discard any priority.
>>>
>>>
>>> nicolai
>>>
>>
>>
>

Re: [Pharo-dev] memoized vs once

[philippe.b...@highoctane.be]

Le 27 janv. 2017 05:55, "Ben Coman"  a écrit :

On Fri, Jan 27, 2017 at 4:32 AM, Eliot Miranda 
wrote:
>
>
> Now, descending to the implementations, I understand that Ben's memorize...
>

btw, I feel a bit of an impostor having it called "my" memorize.  It was
Torsten's initiative based on gist by John Cromartie.
https://pharo.fogbugz.com/f/cases/14458/Add-BlockClosure-memoized


Thx for the link.

So, multi arg blocks someone?

Phil


cheers -ben

>

Re: [Pharo-dev] error "please insert disk" (windows vm)

[philippe.b...@highoctane.be]

Le 14 janv. 2017 14:47, "Sven Van Caekenberghe"  a écrit :


> On 14 Jan 2017, at 14:44, Peter Uhnák  wrote:
>
> Hi,
>
> I think a regression occured in Pharo VM related to this, for example
when I open the dialog
>
> MorphicUIManager new fileSave: ''
>
> In old win32 vm (Oct 12 2016) I am placed in the image directory and I
see the whole hierarchy
> ​
> 
>
> but with new VM (Jan 14 2017) I see just an empty tree with only hard
drives available
>
> 
> ​
> My own FileDialog implementation doesn't suffer from this,

Which we still should include in the base image since (1) it is better and
(2) it is an excellent Spec example.


Sure but the old one can do image and text previews. Is the new one doing
that?


> so maybe the Morphic one is just accessing the data in a weird way?
>
> Peter
>
>
> On Sat, Jan 14, 2017 at 11:21 AM, Nicolai Hess 
wrote:
>
>
> 2016-01-15 0:07 GMT+01:00 Nicolai Hess :
> attached a patch on
> http://bugs.squeak.org/view.php?id=7841
> I think this could be applied on pharo win32 source as well.
> maybe with some small changes
>
> 2015-11-16 10:00 GMT+01:00 Nicolai Hess :
> I opened another bug report at mantis - > http://bugs.squeak.org/view.
php?id=7841
>
> I can create a patch with the proposed solution.
>
>
>
> 2015-11-06 8:42 GMT+01:00 Nicolai Hess :
> we have the following bug report
> 16928 "no disk in the drive" reply to World | Save As (and other places)
>
> "On a clean Pharo4.0 #40618 image, on Windows 7
> World Menu | Save As brings up a modal alert window, "There is no disk in
the drive. Please insert a disk into drive "
>
> On my system, it does this 4 times.
>
> I'm assuming that each instance refers to one of the card-reader drives
which are attached, but without a card inserted.
>
> This is a pain to deal with every single time a File Browser or World |
Save As dialog is opened.
>
> Could the alerts either be
>  - only raised when that specific drive is requested by a user action
> or, less preferably
>  - given by a non-modal window, and fading away after a period"
>
> I was able to reproduce this error on squeaks and pharos window vm.
> (insert a usb card reader, with card, wait some time , remove only the
card,
> every access on this drive, for example open a FileList and scroll to the
drive letter).
>
>
> The solution I found is to call SetErrorMode(SEM_FAILCRITICALERRORS)
>
> I would like to propose the following change to sqwin32directory.c
> wrap the call to FindFirstFileW/FindNextFileW with
>
> UINT prevMode = SetErrorMode(SEM_FAILCRITICALERRORS);
> call   FindFirstFileW/FindNextFileW
> SetErrorMode(prevMode);
>
> ...
>
> and call this functions in at least dir_lookup()
> (the other file/directory methods are save).
>
> Alternative solution, we could call the SetErrorMode function once at
program start
> but I don't know if there are other "useful" errors message that we don't
want to disable.
>
> I tested both solution, both seems to work fine.
>
> What do you think?
>
>
>
>
>
>
>
> Any chance to include this  ? Or is it already done, if so I can close
the issue at pharo.fogbugz   and bugs.squeak.org
>
>

Re: [Pharo-dev] happy and bold new year

[philippe.b...@highoctane.be]

Doru,

Wow.

I have to say that in the face of other technologies there is often the
force that lures me back go them. But they do not have the same feel. This
ability to understand and be able to dig down is unmatched.

I was reading this mail this morning and it echoes your point pretty nicely:
"I  hear a lot about "seeking meaning," especially in the face of tragedy
and uncertainty. But how would you know it if you tripped over it? I doubt
it's like the justice's definition of pornography—I'll know it when I see
it.

I'd think our brief time here is about *creating* meaning, first and
foremost for ourselves. When we have a lighted path, a goal for our journey
(whether or not we reach our destination), we tend to serve a greater
purpose. "Journey" comes from the French *jornee *which means a day, or a
day's travels. It refers to our daily activity.

When we we are engaged in neither meaning nor happiness, we waste our days.
When we are engaged in meaning but not happiness, we are sacrificing our
days. When we are engaged in high happiness but little meaning, we are in a
stimulating or addictive environment. Only when we are immersed in both
happiness and meaning do we create an optimal, contributing life.

I don't know about you, but I'd prefer to take both my meaning and
happiness out of others' hands, and create them both myself".--Alan Weiss

Definitely applies to our tech.

Happy New Year!


Phil



Le 9 janv. 2017 10:31, "Tudor Girba"  a écrit :

> Happy New Year, everyone!
>
> Over the last year, I went through a rather extensive tour and I directly
> exposed Moose, GT and Pharo to some 2000+ technical people through various
> sessions and trainings at conferences and companies. The tour will continue
> this year.
>
> Most of the sessions are not directly about Moose, GT or Pharo, but about
> broader topics that are served through what we do around here. These topics
> can relate to solving problems without reading code, to steering agile
> architecture, or more recently, to even broader topics like software
> environmentalism. If you are wondering what software environmentalism is,
> please take a look at this talk:
> https://youtu.be/N3l3eB62oSw?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA
>
> I now have the confirmation that there is a whole space which is
> unaddressed by mainstream technologies. Often people find themselves
> frustrated having to build their systems on top of opaque technologies with
> not much hope of understanding what is going on under the hood both because
> they do not have access to what is behind and because they are provided
> lack the tools to investigate. You see, developers are suppose to have the
> coolest job on the planet, and many of them are unhappy. This has to
> change, and we can do that.
>
> In a conversation I had with a highly respected researcher, after
> explaining how our tools allow us to work, he noted reluctantly “so, you
> are claiming that you are practicing a fundamentally different software
> engineering?”. This question took me a little by surprise because the only
> answer I found myself being able to provide was “yes”. I sent him this talk:
> https://youtu.be/XWOOJa3kEa0?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA
>
> It is strange to be in the position to tell the world that we are
> constructing something fundamentally better, but I really do believe that
> we are.
>
> I wish you a happy and bold new year!
>
> Cheers,
> Doru
>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Every thing should have the right to be different."
>
>
>
>
>
>

Re: [Pharo-dev] ***Important*** Snapcraft pharo package for Pharo 50

[philippe.b...@highoctane.be]

Then use the Centos VM

It is for older libC.

Phil

Le 8 janv. 2017 20:01, "stepharong"  a écrit :

> On Fri, 06 Jan 2017 18:31:59 +0100, Dale Henrichs <
> dale.henri...@gemtalksystems.com> wrote:
>
> Stef,
>
> RE: why they "cannot install Pharo" --- I'd guess it is because Pharo
> requires 32 bit libraries and those are not available in the current Linux
> releases by default ... to install the 32 bit libraries requires sudo
> privileges and students aren't going to be able to do it themselves and the
> sysadmins aren't going to want to have to add 32 bit libraries to a bunch
> of linux machines just for pharo ... just a guess .
>
>
> I was talking about the sys admin and I think that there is a problem with
> the different libC and they do not want to mess everything because we did
> not plan it.
>
> Dale
>
> On 01/06/2017 05:38 AM, Stephane Ducasse wrote:
>
> Hi pharoers
>
> I want to share with you my experience with trying to use Pharo at the
> University here on Linux.
> I think that they are on Ubuntu and ... the sys admin told me that they
> cannot install Pharo :(
> Since I'm not expert in Linux install I cannot help ;(
>
> So we will probably use windows.
> Now they told me that what would be nice is to get a snap for Pharo
> based on snapcraft.io.
>
> Does any of you have a snap description or willing to help so that we can
> get
> a snap for Pharo50? then for Pharo60?
>
> Stef
>
>
>
>
>
> --
> Using Opera's mail client: http://www.opera.com/mail/
>

Re: [Pharo-dev] ***Important*** Snapcraft pharo package for Pharo 50

[philippe.b...@highoctane.be]

There are docker images for Pharo already.

E.g. https://hub.docker.com/r/geraudster/docker-pharo/~/dockerfile/

Phil

Le 6 janv. 2017 19:11, "Damien Pollet"  a écrit :

> Docker seems pretty nice as well, with the added bonus that it can be
> hosted on Mac and Windows, and is probably a bit lighter since containers
> are not full-system.
>
> About installing Pharo, I'd guess that the adhoc install procedure is a
> problem. Whatever the dependencies, it's easier for admins to install stuff
> if it's just another package that fits with the rest of their distribution.
>

Re: [Pharo-dev] No Projects at smalltalkhub

[philippe.b...@highoctane.be]

Upon login I saw none of my projects.
The I put a direct Url to one of them.
And there were my projects on the side.

Phil

Le 6 janv. 2017 16:58, "Esteban Lorenzano"  a écrit :

>
> On 6 Jan 2017, at 16:38, p...@highoctane.be wrote:
>
> I went to a project I knew and there the list was populated.
>
> On home screen it was blank.
>
>
> Sorry Phil, this feedback is a bit cryptic. No idea what are you saying :)
>
> Esteban
>
>
> Phil
>
> On Fri, Jan 6, 2017 at 3:14 PM, Nicolai Hess 
> wrote:
>
>> No wait, now the list of teams is empty ? I am not in any team anymore ?
>> But I can see my name in the list of members of project Pharo
>>
>> 2017-01-06 15:05 GMT+01:00 Nicolai Hess :
>>
>>>
>>>
>>> 2017-01-06 15:01 GMT+01:00 Esteban Lorenzano :
>>>
 I restarted it and now I see 3 projects… is that correct?

>>>
>>> YES
>>>
>>> Thanks.
>>>
>>>
>>>

 Esteban

 On 5 Jan 2017, at 23:16, Nicolai Hess  wrote:

 All my projects at smalltalkhub.com are gone - again.
 (http://smalltalkhub.com/#!/~NicolaiHess)



>>>
>>
>
>

Re: [Pharo-dev] Redline: Talking Runtime basics ...

[philippe.b...@highoctane.be]

Isn't there a typo in the first exptession?

Also the list contains a lot of RB things. What purpose do they have in a
bootstrap image?

Same for RelationSlot and X11 something.

Is there a scope and purpose statement for the bootstrap somewhere?

Phil

Le 31 déc. 2016 05:47, "Ben Coman"  a écrit :

> So for curiosity...
>
> $  $PHARO bootstrap.image eval "Object allSubclasses size"
> 1677
>
> $  $PHARO bootstrap.image eval "Object allSubclasses size"
> 837
>
> $  $PHARO bootstrap.image eval "Object class printHierarchy" >
> /tmp/60334-bootstrap-hierarchy.txt
> (see attached)
>
> cheers -ben
>
>
> On Sat, Dec 31, 2016 at 4:42 AM, Pavel Krivanek
>  wrote:
> > It is better to use smaller bootstrapped image without Monticello but it
> is
> > still quite big.
> >
> > https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.
> 0-Step-01-00-Bootstrap/lastSuccessfulBuild/artifact/bootstrap.zip
> >
> > -- Pavel
> >
> > 2016-12-30 18:13 GMT+01:00 Ben Coman :
> >>
> >> On Fri, Dec 30, 2016 at 7:51 AM, James Ladd 
> wrote:
> >> > Hi Pharo People,
> >> >
> >> > I have continued work on Redline Smalltalk and I'm wanting to discuss
> >> > what
> >> > the absolute minimum
> >> > set of Classes and method should be included in the Redline Runtime.
> >> >
> >> > Would anyone here like to participate in that discussion?
> >> >
> >> > - James.
> >> > Redline Smalltalk 
> >>
> >> Nice to hear you are continuing.
> >> I'm not very knowledgable on this, but I'll show you how to pull some
> >> data from the work on producing a minimal image.
> >>
> >> 1. From PharoLauncher > Templates > Pharo 6.0(beta)
> >> download/create an image of build "60334-minimal".
> >> 2. Right-click on the image and choose [Copy pathname]
> >> 3. In a shell, change to that directory, and execute the following
> >> $ ../../VMs/spur/pharo 60334-minimal.image eval "Object
> allSubclasses
> >> size"
> >> ==> 2801
> >> $ ../../VMs/spur/pharo 60334-minimal.image eval "Object class
> >> allSubclasses size"
> >> ==> 1399.
> >> $ ../../VMs/spur/pharo 60334-minimal.image eval "Object class
> >> printHierarchy" > /tmp/60334-minimal-class-hierarchy.txt
> >>
> >> I've attached the output of that last one.
> >>
> >> 4. For comparison, in a standard 60334 image,
> >> Object allSubclasses size "==>11923".
> >> Object class allSubclasses size "==>5959".
> >>
> >> Now in Pharo 6, the minimal image starts with a standard image and
> >> strips these things out...
> >>
> >> https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-
> Minimal/ws/output.txt
> >>
> >> In Pharo 7, there will be a new build system that it will start with a
> >> minimal image and build it up to a normal image.  So this may provide
> >> a better way to understand the order that things need to be
> >> implemented.
> >>
> >> cheers -ben
> >
> >
>

Re: [Pharo-dev] Redline: Talking Runtime basics ...

[philippe.b...@highoctane.be]

Amber took a bunch of classes and this could be a nice starting point for
fundamentals.

Phil

Le 30 déc. 2016 18:14, "Ben Coman"  a écrit :

> On Fri, Dec 30, 2016 at 7:51 AM, James Ladd  wrote:
> > Hi Pharo People,
> >
> > I have continued work on Redline Smalltalk and I'm wanting to discuss
> what
> > the absolute minimum
> > set of Classes and method should be included in the Redline Runtime.
> >
> > Would anyone here like to participate in that discussion?
> >
> > - James.
> > Redline Smalltalk 
>
> Nice to hear you are continuing.
> I'm not very knowledgable on this, but I'll show you how to pull some
> data from the work on producing a minimal image.
>
> 1. From PharoLauncher > Templates > Pharo 6.0(beta)
> download/create an image of build "60334-minimal".
> 2. Right-click on the image and choose [Copy pathname]
> 3. In a shell, change to that directory, and execute the following
> $ ../../VMs/spur/pharo 60334-minimal.image eval "Object allSubclasses
> size"
> ==> 2801
> $ ../../VMs/spur/pharo 60334-minimal.image eval "Object class
> allSubclasses size"
> ==> 1399.
> $ ../../VMs/spur/pharo 60334-minimal.image eval "Object class
> printHierarchy" > /tmp/60334-minimal-class-hierarchy.txt
>
> I've attached the output of that last one.
>
> 4. For comparison, in a standard 60334 image,
> Object allSubclasses size "==>11923".
> Object class allSubclasses size "==>5959".
>
> Now in Pharo 6, the minimal image starts with a standard image and
> strips these things out...
> https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-
> Minimal/ws/output.txt
>
> In Pharo 7, there will be a new build system that it will start with a
> minimal image and build it up to a normal image.  So this may provide
> a better way to understand the order that things need to be
> implemented.
>
> cheers -ben
>

Re: [Pharo-dev] Removing most of the windowing code

[philippe.b...@highoctane.be]

Need help with the VM cleaning?

Le 24 nov. 2016 08:13, "Ronie Salgado"  a écrit :

> Hello,
>
> I am working on removing most of windowing code from the VM, and in trying
> to unify the platform specific code of the VM. In the MinimalistHeadless
> branch of https://github.com/ronsaldo/opensmalltalk-vm I made the
> following changes:
>
> - Unified standard CMake building scripts for Unixes. I hate autoconf. I
> want to use them in Windows too.
> - Refactoring the Unix entry points. I am trying to remove a lot of code
> for simplfying stuff.
> - Null window driver for true headless.
> - Optional SDL2 based traditional display backend for compatibility
> reasons, and because the extra Morphic worlds using OSWindow are a bit
> unstable.
>
> So far I managed to run a standard Pharo 6 image using this custom VM in
> Linux. Windows and Mac are coming next. Hopefully this is going to fix the
> problems with duplicated events when using OSWindow in Windows.
>
> I am also planning on making a standard interface for embedding the VM in
> an application, at least as a static library. With this new building
> system, this seems to be easy to do.
>
> BTW. When I tried the minimalistic Pharo image, in a completely headless
> VM, I got the following error:
>
> [ "Ugh  now this is a biggie - a system that does not support
> any of the display depths at all."
> Smalltalk
> logError:
> 'Fatal error: This system has no support for any display depth at
> all.'
> inContext: thisContext.
> Smalltalk quitPrimitive"There is no way to continue from here" ] in
> DisplayScreen>>findAnyDisplayDepth
> DisplayScreen>>findAnyDisplayDepthIfNone:
> DisplayScreen>>findAnyDisplayDepth
> DisplayScreen>>setExtent:depth:
> DisplayScreen class>>startUp
>
> As a workaround, I am doing the following for ioHasDisplayDepth with the
> null driver:
>
> sqInt ioHasDisplayDepth(sqInt depth)
> {
> return true;
> }
>
> In DisplayScreen class >> startUp we have the following:
> startUp  "DisplayScreen startUp"
> Display setExtent: self actualScreenSize depth: Display nativeDepth.
> Display beDisplay
>
> Does it make sense, to always trying to create a display in startup time?
>
> Best regards,
> Ronie
>

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

[philippe.b...@highoctane.be]

Le 23 nov. 2016 12:07, "Igor Stasenko"  a écrit :
>
>
>
> On 23 November 2016 at 12:41, p...@highoctane.be 
wrote:
>>
>>
>>
>> On Wed, Nov 23, 2016 at 10:51 AM, Igor Stasenko 
wrote:
>>>
>>>
>>>
>>> On 23 November 2016 at 10:50, p...@highoctane.be 
wrote:



 On Wed, Nov 23, 2016 at 12:53 AM, Eliot Miranda <
eliot.mira...@gmail.com> wrote:
>
>
>
> On Tue, Nov 22, 2016 at 10:26 AM, Sven Van Caekenberghe 
wrote:
>>
>>
>> > On 22 Nov 2016, at 19:16, p...@highoctane.be wrote:
>> >
>> >
>> >
>> > On Tue, Nov 22, 2016 at 5:57 PM, Igor Stasenko 
wrote:
>> >
>> >
>> > On 15 November 2016 at 02:18, Eliot Miranda <
eliot.mira...@gmail.com> wrote:
>> > Hi Phil,
>> >
>> > On Thu, Nov 10, 2016 at 2:19 AM, p...@highoctane.be <
p...@highoctane.be> wrote:
>> >
>> >
>> > On Thu, Nov 10, 2016 at 10:31 AM, Denis Kudriashov <
dionisi...@gmail.com> wrote:
>> >
>> > 2016-11-10 9:49 GMT+01:00 p...@highoctane.be :
>> > Ah, but then it may be more interesting to have a data image
(maybe a lot of these) and a front end image.
>> >
>> > Isn't Seamless something that could help us here? No need to bring
the data back, just manipulate it through proxies.
>> >
>> > Problem that server image will anyway perform GC. And it will be
slow if server image is big which will stop all world.
>> >
>> > What if we asked it to not do any GC at all? Like if we have tons
of RAM, why bother? Especially if what it is used to is to keep datasets:
load them, save image to disk. When needed trash the loaded stuff and
reload from zero.
>> >
>> > Basically that is what happens with Spark.
>> >
>> >
http://sujee.net/2015/01/22/understanding-spark-caching/#.WCRIgy0rKpo
>> > https://0x0fff.com/spark-misconceptions/
>> >
>> > While global GC may not be useful for big-data scavenging probably
will be for any non-trivial query.  But I think I see a misconception
here.  The large RAM on a multiword machine would be divided up between the
cores.  It makes no sense to run a single Smalltalk across lots of cores
(we're a long way from having a thread-safe class library).  It makes much
more sense to have one Smalltalk per core.  So that brings the heap sizes
down and makes GC less scary.
>> >
>> > yep, that approach what we're tried in HydraVM
>> >
>> >
>> > and Tachyon/Alluxio is kind of solving this kind of issue (may be
nice to have that interacting with Pharo image). http://www.alluxio.org/
This thing basically keeps stuff in memory in case one needs to reuse the
data between workload runs.
>> >
>> > Sure.  We have all the facilities we need to do this.  We can add
and remove code at runtime so we can keep live instances running, and send
the code to them along with the data we want them to crunch.
>> >
>> >
>> > Or have an object memory for work and one for datasets (first one
gets GC'd, the other one isn't).
>> >
>> > Or have policies which one can switch.  There are quite a few
levers into the GC from the image and one can easily switch off global GC
with the right levers.  One doesn't need a VM that doesn't contain a GC.
One needs an image that is using the right policy.
>> >
>> > or just mark whole data (sub)graphs with some bit, telling GC to
skip over this so it won't attempt to scan it treating them as always
alive..
>> > this is where we getting back to my idea of heap spaces, where you
can toss a subgraph into a special heap space that has such policy, that it
is never scanned/GCed automatically and can be triggered only manually or
something like that.
>> >
>> > Could be very useful for all kinds of large binary data, like
videos and sounds that we can load once and keep in the heap space.
>> >
>> > How hard would it be to get something like that?
>>
>> Large binary data poses no problem (as long as it's not a copying
GC). Since a binary blob contains no subpointers, no work needs to be done.
A 1M or 1G ByteArray is the same amount of GC work.
>
>
> +1


 Amen to that. But a dataset made of a gazillion of composites is not
the same, right?

>>> yep, as soon as you have references in your data, you add more work for
GC
>>
>>
>> That's what I tought. I have seen Craig Latta marking some objects with
special flags in the object headers. Could there be some generic mechanism
there now that we have 64-bit, super large headers? Like setting/resetting
a kind of bitmask to let some spaces be GC'd or left alone? Things that we
could manage image side?
>>
> well, adding bit(s) is just a simplest part of story. the main one is
implement GC discipline to not walk over marked object(s), but as well, is
by having a mechanism to ensure that marked object(s) form a 

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

[philippe.b...@highoctane.be]

Great.

Le 14 nov. 2016 11:23, "Esteban Lorenzano"  a écrit :

>
> On 14 Nov 2016, at 10:00, Pavel Krivanek  wrote:
>
> Revert the new API. It was mistake to integrate it in the code freeze
> phase.
>
>
> yep, that’s accurate :)
>
> Esteban
>
>
> -- Pavel
>
> 2016-11-14 9:53 GMT+01:00 Nicolai Hess :
>
>>
>>
>> 2016-11-14 9:42 GMT+01:00 Pavel Krivanek :
>>
>>> Well, we will revert the change
>>>
>>>
>> revert the autodeprecation or the new api ?
>> I made a fix for case 19336 Finder and FileList can now work with the new
>> api.
>>
>>
>>> -- Pavel
>>>
>>> 2016-11-13 17:33 GMT+01:00 Nicolai Hess :
>>>


 2016-11-13 10:06 GMT+01:00 Nicolai Hess :

>
>
> 2016-11-11 10:55 GMT+01:00 Pavel Krivanek :
>
>> Hi,
>>
>> the API of Pragma was changed in quite dangerous way.
>> In past we had:
>> - #selector to access to method selector
>> - #keyword to access to pragma selector
>>
>> now we have:
>> - #methodSelector to access to method selector
>> - #selector to access to pragma selector
>>
>> That means that the meaning of the message #selector was changed and
>> it can cause some problems (like some currently failing tests [1]). The
>> #selector message was deprecated in the middle of the transition process 
>> so
>> most of usages should be already rewritten to #methodSelector but we
>> need to be aware of it.
>>
>> [1] https://pharo.fogbugz.com/f/cases/19333/17-more-tests-fa
>> iling-due-to-MockSettings-class-Object-doesNotUnderstand-moc
>> ksystemsettings-SettingTreeBuilder-mocksystemse
>>
>
> And it broke finder.
> 19336
> 
> Finder broken: Can not search for pragmas
>

 And FileList can not show .cs files anymore.
 I think both has something to do with a lock (?) during the transform
 of the autodeprecation.


>
>
>>
>> Cheers
>> -- Pavel
>>
>
>

>>>
>>
>
>

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[philippe.b...@highoctane.be]

What has VTermOutputDriver to do with FilePolicy?

Le 23 oct. 2016 12:22, "stepharo"  a écrit :

> In the bug tracker
>
> https://pharo.fogbugz.com/f/cases/18650/VTermOutputDriver
>
> https://pharo.fogbugz.com/f/cases/18649/
>
> we got a lot of problems because the monkey and our build process were
> using the api we wanted to change.
>
> So now we are making the changes one by one.
>
> I hope to work on it during the next sprint.
>
>
> Stef
>
>
>
> Le 23/10/16 à 11:31, p...@highoctane.be a écrit :
>
> Where?
>
> On Sun, Oct 23, 2016 at 10:42 AM, stepharo  wrote:
>
>> Note that all the work on making sure that the image is not writing files
>> when it is on read only mode is part of making coral installable on unix.
>> Now if people wants coral they can join the effort.
>>
>> stef
>>
>>
>
>

Re: [Pharo-dev] new text model / TxText [was Re: [ANN] Sparta v1.1]

[philippe.b...@highoctane.be]

Is there no way Igor can finish this up?

Phil

Le 23 oct. 2016 12:19, "stepharo"  a écrit :

>
> Hi Stef,
>>
>> We are not throwing away anything. The goal is not to produce a new
>> model, the goal is to find one that matches the requirements.
>>
> Don't play with words.
>
> We already learnt a lot from TxText, but it has limitations in how to deal
>> with things that are not only text.
>>
> I can imagine.
>
>> We have no intention of producing an unfinished text model :).
>>
> Me neither with igor and txText yet life decided otherwise. You see I
> spent at 10 months of salary on txText.
>
>>   This is a critical component for us. Please let us work for a couple of
>> months and we get back with news.
>>
>> Cheers,
>> Doru
>>
>>
>> On Oct 22, 2016, at 8:31 PM, stepharo  wrote:
>>>
>>> Hi aliaksei
>>>
>>> I thought that you were just changing the internal representation of
>>> txText to use Ropes
>>> and building on top of / improving txText
>>> I did not think that you were throwing away all the work igor did.
>>> Because he spent a lot of time
>>>
>>> designing the text model and making it is scalable - and now I read that
>>> apparently it was not scalable enough.
>>> I'm wondering what will happen if suddenly you disappear: we will get
>>> two unfinished textmodel
>>> and use an old one? When do you think that you will have a working
>>> usable by other for real text model?
>>> Stef
>>>
>>> Le 22/10/16 à 12:29, Aliaksei Syrel a écrit :
>>>
 As Doru already mentioned text editor is an important part of the
 tools. There are some requirements a text editor should fulfil.

 • Support of large files ( >> 100mb)
 • Support of large pieces of text located in memory
 • Allow developers to embed visual elements (pictures,
 interactive elements, custom elements)
 • Support of more sophisticated layouts rather than line-based.
 For example columns.
 • Line breaking
 • Text wrapping
 • Hyphens
 • Should be fast
 Tests show that TxText model is very nice for basic cases, works well
 for "normal" use.
 However, when it comes to extreme cases linked list of spans just
 fails, while rope shows great performance - and it also scales.

 Cheers,
 Alex

 On 19 October 2016 at 23:51, Denis Kudriashov 
 wrote:

 2016-10-19 18:06 GMT+02:00 Aliaksei Syrel :
   - Added initial text support, for instance rendering and high
 precision measurement.

 I look at code and it seems you implemented another one new text model?
 Why you not use TxText?

 --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Some battles are better lost than fought."
>>
>>
>>
>>
>>
>>
>>
>
>

Re: [Pharo-dev] [ANN] Tealight

[philippe.b...@highoctane.be]

Looks nice.

Is there a way to turn the dynamic routes done in the "experiments" mode
into a set of methods + pragmas?

Phil

Le 8 oct. 2016 10:16, "Torsten Bergmann"  a écrit :

> Hi,
>
> I wrote a small extension "Tealight" for the Teapot framework that makes it
> even easier to experiment with web based interfaces/web calls into Pharo
> running on the server side.
>
> It additionally allows you to easily define and generate a simple or
> versioned web
> interface for your own apps.
>
> With this extension REST  annotated methods like
>
>greeting: aRequest
>   
>
>   ^'HelloWorld from Pharo'
>
> are transformed into dynamic Teapot routes and can be accessed easily via
> web.
>
> You can use two pragmas:
>
>   #REST_API:pattern:  for standard APIs
>   #REST_API:versions:pattern  for versioned APIs
>
> Full docu explaining how to use it is added on
>
>   https://github.com/astares/Tealight
>
> It also shows the new custom "Teaspoon" inspector extension tool
> implemented by
> Attila Magyar - which is really cool to experiment and call the web methods
> without a web browser or Zinc scripts.
>
> So far there is no config for Tealight for the catalog yet, will add this
> soon.
> So for the time being you need to load the latest version via
>
>   Metacello new
> repository: 'github://astares/Tealight/repository';
> baseline: 'Tealight';
> load
>
> to follow the docu description.
>
> Have fun!
>
> Bye
> T.
>
>

Re: [Pharo-dev] Getting Pharo to Mars?

[philippe.b...@highoctane.be]

I am already working in an ESA oroject.

Le 30 sept. 2016 00:05, "Richard Sargent" <
richard.sarg...@gemtalksystems.com> a écrit :

> Clément Bera-4 wrote
> > The first thing is to get naturalised as a US citizen.
>
> I think you would be much further ahead to find someone who works for the
> ESA.
> (Or maybe approach the ESA itself directly!)
>
>
>
> > It seems that the space market has been opened to private companies in
> the
> > US, but they're still quite skeptical about sharing knowledge with non
> > american citizens. If you want to work with Space X, you have either to
> be
> > an american citizen or have something they really really really want to
> > convince them to work with you (and even so, it's likely your native
> > country matters).
> >
> > Quoting their website:
> >
> > *To conform to U.S. Government space technology export regulations,
> > applicant must be a U.S. citizen, lawful permanent resident of the U.S.,
> > protected individual as defined by 8 U.S.C. 1324b(a)(3), or eligible to
> > obtain the required authorizations from the U.S. Department of State.
> > Learn
> > more about ITAR here.*
> >
> >
> >
> > On Thu, Sep 29, 2016 at 6:27 AM,
>
> > phil@
>
> >  
>
> > phil@
>
> > 
> > wrote:
> >
> >> Given
> >>
> >> http://waitbutwhy.com/2016/09/spacexs-big-fking-rocket-the-
> full-story.html
> >>
> >> we should find some way to get Pharo into it somehow.
> >>
> >> Anyone having ideas on how to do that?
> >>
> >> Phil
> >>
>
>
>
>
>
> --
> View this message in context: http://forum.world.st/Getting-Pharo-to-Mars-
> tp4917390p4917478.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

[philippe.b...@highoctane.be]

How is all of this PackageManifest mechanism working?

Doc anywhere?

Phil

Le 16 sept. 2016 17:02, "Nicolai Hess"  a écrit :



2016-09-16 0:19 GMT+02:00 p...@highoctane.be :

> I'd be more interested with a package level doc than a class doc or test.
>
> Package level doc is quite useful to outline how some things are working
> together, something which is quite hard to figure out except by reading
> external doc or inferring things by walking through the code or a running
> test.
>


Why don't we have yet package comments ?
I see there is some support for it in PackageManifest, I remember there was
some work (people working) on support for Nautilus, no?

maybe something like this, (see attached file)
Nautilus comment pane
on class selection -> show class comment
no class selection -> show package comment (class side #description of
package manifest of this package)
you can even add or change the (package) comment, it will compile a proper
#description method on the manifest class)




>
> Having the ability to read about a package would be very useful.
> Basically, this is what Java provides.
>
> http://docs.oracle.com/javase/7/docs/technotes/tools/solaris
> /javadoc.html#packagecomment
>
> Phil
>
>
> On Thu, Sep 15, 2016 at 8:45 PM, stepharo  wrote:
>
>> Hi all
>>
>> I want something similar in the spirit to PythonDocTest
>> https://docs.python.org/2/library/doctest.html
>>
>> I'm talking about
>>
>> basename
>> "Returns the base of the basename,
>> i.e.
>> /foo/gloops.taz basename is 'gloops.taz'
>> / basename is '/'"
>>
>> Pragmas do not work well i.e.,
>> basename
>> "Returns the base of the basename"
>>  > 'gloops.taz'>
>>
>>
>> We should invent a syntax to be put inside comments and that we can
>> easily parse because we need to improve
>> the use and discovery of the library.
>>
>> I was thinking about
>>
>> basename
>> "Returns the base of the basename"
>> "
>> '/foo/gloops.taz' asFileReference basename
>> >>> 'gloops.taz'
>> "
>>
>> Do you have any idea?
>>
>> I cannot not do anything and just complain that our methods are not that
>> well documented.
>> We as a community should take this and build an super cool system.
>>
>> I tried and defined >>> on Object to see if it works!
>>
>> Object >>> aResultingObject
>> "If the method comment contains >>> then it is a pharo documentated
>> test. We can check that it is true."
>>
>> "
>> '/foo/gloops.taz' asFileReference basename
>>>>> 'gloops.taz'
>> "
>>
>> ^ self = aResultingObject
>>
>>
>> Stef
>>
>>
>>
>

Re: [Pharo-dev] PharoJS ESUG 2016 Demo files

[philippe.b...@highoctane.be]

But http://blackpagedigital.com/snowglobe/ may be able to.

Craig told me they did something for a Pharo image at ESUG.

Phil

Le 10 sept. 2016 17:20, "Hilaire"  a écrit :
>
> Hi,
>
> Can PharoJS be used to turn Dr. Geo as JavasScript appliation running in
> the browser?
>
> Thanks
>
> Hilaire
>
> Le 09/09/2016 à 10:51, Noury Bouraqadi a écrit :
> > Hi,
> >
> > The Pharo 4.0 image + related files used in the PharoJS ESUG 2016 demo
> > are now available for download at
> > https://pharojs.github.io/faq.html#demoEsug2016
> >
> > Best,
> > Noury
> >
>
> --
> Dr. Geo
> http://drgeo.eu
>
>

Re: [Pharo-dev] [OFF-TOPIC] looking for your wisdom... video conference service?

[philippe.b...@highoctane.be]

Not true.

Terf experience would help in focusing the meeting and make it like a real
assembly.

We could take a conference theater with podium etc to make it work.

I can help facilitating.

And we can make an intro video to explain to people how they could just sit
their avatar to listen, raise the issues and use the chat or share a window.
And go to the lectern to expose something.

We can also screenrecord it all for reference and post it back to youtube
as a private video.

Phil

Le 9 sept. 2016 09:25, "Norbert Hartl"  a écrit :

Well, on the one hand this would be super cool. On the other hand nobody
will listen to the meeting because everyone's playing with terf :)

Norbert
> Am 09.09.2016 um 08:51 schrieb Ron Teitelbaum :
>
> Terf?  www.3dicc.com
>
> Ron Teitelbaum
>
> -Original Message-
> From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of
Esteban Lorenzano
> Sent: Friday, September 9, 2016 2:47 AM
> To: Pharo Development List
> Subject: [Pharo-dev] [OFF-TOPIC] looking for your wisdom... video
conference service?
>
> Hi,
>
> In the board we decided that we need to have a better support for public
meetings (particularly for consortium meetings but also for others).
> So we wanted to explore other services that would allow is more than 10
persons participating (this limit is annoying).
> Now, I know google hangouts was able to provide more than 10 connections
(paying), but now I do not find it… maybe I was mistaken?
> Do you have any other service we can try?
>
> Thanks,
> Esteban
>
>

Re: [Pharo-dev] [OFF-TOPIC] looking for your wisdom... video conference service?

[philippe.b...@highoctane.be]

Why are we not using 3DICC Terf for these?

Would work wonderfully.

We can have a persistent area, sound and webcam support, slides, 

Ron, how would it work cost wise for the Pharo Consortium to handle
meetings in your servers?

Phil

Le 9 sept. 2016 09:25, "Norbert Hartl"  a écrit :

> Well, on the one hand this would be super cool. On the other hand nobody
> will listen to the meeting because everyone's playing with terf :)
>
> Norbert
> > Am 09.09.2016 um 08:51 schrieb Ron Teitelbaum :
> >
> > Terf?  www.3dicc.com
> >
> > Ron Teitelbaum
> >
> > -Original Message-
> > From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of
> Esteban Lorenzano
> > Sent: Friday, September 9, 2016 2:47 AM
> > To: Pharo Development List
> > Subject: [Pharo-dev] [OFF-TOPIC] looking for your wisdom... video
> conference service?
> >
> > Hi,
> >
> > In the board we decided that we need to have a better support for public
> meetings (particularly for consortium meetings but also for others).
> > So we wanted to explore other services that would allow is more than 10
> persons participating (this limit is annoying).
> > Now, I know google hangouts was able to provide more than 10 connections
> (paying), but now I do not find it… maybe I was mistaken?
> > Do you have any other service we can try?
> >
> > Thanks,
> > Esteban
> >
> >
>
>
>

Re: [Pharo-dev] [Ann] New Seamless version 0.9.0

[philippe.b...@highoctane.be]

What is TostSerializer ?

Le 5 sept. 2016 15:19, "Denis Kudriashov"  a écrit :

> Hi,
>
> I released new version of Seamless 0.9.0.
> It is based on specialized TostSerializer instead of Fuel.
>
> This version is ~4 times faster than previous one and produce much compact
> data packets.
> For example Fuel based version takes 400 bytes to return small integer as
> result of message send. Now it is just 21 bytes.
>
> Pharo 5 and 6 are supported.
>

Re: [Pharo-dev] [ANN] Sparta v1.0

[philippe.b...@highoctane.be]

Sweet.

How does this handles accelerated graphics?

Phil

Le 5 sept. 2016 11:52, "Aliaksei Syrel"  a écrit :

> Hi
>
> I am happy to announce the release of Sparta v1.0 for Pharo 5 and Pharo 6.
> https://github.com/syrel/Sparta/tree/v1.0
> For a moment only Linux and Mac are supported.
>
> It can be bootstrapped with the following script:
>
> Metacello new
>   baseline: 'Sparta';
>   repository: 'github://syrel/sparta:v1.0/src';
>   load: #file:core
>
>
> (on linux install 32bit libgtk-2, lingtk-3 and libstdc++)
> (script for ubuntu http://ws.stfx.eu/IEAWCUC18BH)
>
> Sparta is an almost stateless vector graphics API for Pharo that provides
> bindings to the Moz2D rendering backend. Moz2D is the extracted graphical
> engine from Mozilla Firefox compiled as standalone shared library together
> with the extern C bindings required to call the engine from Pharo.
>
> - developed with the help of Iceberg
>  (thanks!) on Github.
> - integrated into travis-ci  using
> smalltalkCI  (great job!).
> - documented using Pillar  (so
> better!) syntax.
>
> Cheers,
> Alex
>

Re: [Pharo-dev] About asClass and friend

[philippe.b...@highoctane.be]

Le 25 août 2016 08:53, "Tudor Girba"  a écrit :
>
> Hi,
>
> There exists already a method for that:
> Symbol>>asClassInEnvironment:
>
> But, what if we introduce:
>
> Symbol>>asClassFrom: anObject
> ^ self asClassInEnvironment: anObject class environment
>
> ?
>
> This would allow us to still script and be dynamic.
>
> Furthermore, as #asClass is meant to be mainly used for convenience, not
performance, I would also propose to make it lookup in thisContext and take
the environment from there. I know that his might sound like magic, but it
would be the default that we are looking for (to always lookup through the
current environment dynamically).
>
> What do you think?

Great. Makes sense.

Can always monkey patch my way anyway. "Pharo is yours" someone said.

But I am not feeling the pain of getting things running in Gemstone from
wild Pharo so, ...

Phil

>
> Cheers,
> Doru
>
>
>
> > On Aug 25, 2016, at 8:34 AM, Yuriy Tymchuk  wrote:
> >
> > Just my 2 cents:
> >
> >
> > instead of
> >
> > #name asClass
> >
> > we have to use
> >
> > self class environment at: #name.
> >
> >
> > Maybe instead of #at: we can have #classNamed:? Or something similar?
Because 1) it’s not obvious that the method will give you a class, what if
in the future and environment can also have a mapping of something else
like packages?
> >
> > Uko
> >
> >> On 25 Aug 2016, at 07:21, stepharo  wrote:
> >>
> >> Hi guys
> >>
> >> We got a meeting at ESUG with all the compiler guys and james from
gemstone.
> >>
> >> Our goal is to have a full tool suite that can be parametrized by
environments (so that
> >>
> >> we can compile code in other space, or compile other code inside
pharo).
> >>
> >> I personnally started this effort one decade ago. Now the introduction
> >>
> >> of #asClass and friend is simply destroying all our efforts. There was
a discussion
> >>
> >> in the past but we are not listened.
> >>
> >> We will
> >>
> >>   - packaged these extensions in a separate package
> >>
> >>   - add rules to ban the use of such method in Pharo
> >>
> >>   - fix all the use (again) to use the correct way to do it.
> >>
> >>
> >> I can understand that for scripting this is easier but it cannot be at
that cost and impact.
> >>
> >> I hope that we will understand but we have to do something else than
> >>
> >> fixing code that breaks our effort.
> >>
> >>
> >> Stef, Marcus, Guille and Luc
> >>
> >>
> >
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "It's not what we do that matters most, it's how we do it."
>
>

Re: [Pharo-dev] The OpenCL bindings/VirtualGPU has been updated to the uFFI

[philippe.b...@highoctane.be]

A chance of this working under Windows 8.1 ?

Phil

Le 24 août 2016 15:20, "Ronie Salgado"  a écrit :

> Hi,
>
> I have just finished updating the OpenCL bindings and the VirtualGPU to
> use the UnifiedFFI in Pharo 5. All of the examples have been tested in Mac
> OS X El Capitan 10.11.6.
>
> Best regards,
> Ronie
>
> P.S: Do not confuse the VirtualGPU with the AbstractGPU. The AbstractGPU
> is an abstraction layer above Vulkan, Direct3D 12 and Metal. The
> AbstractGPU is used as the foundation for Woden 2.
>

Re: [Pharo-dev] About asClass and friend

[philippe.b...@highoctane.be]

Ah, I am using that a lot to parametrize software.

On one hand Pharo is breaking with the past, on the other one it sticks
with it as much as possible? #MeConfused asHell.

#SomeSymbol asClass looks very practical and cleaner that looking the class
dictionary with at: #SomeSymbol

Phil

Phil

Le 25 août 2016 07:22, "stepharo"  a écrit :

> Hi guys
>
> We got a meeting at ESUG with all the compiler guys and james from
> gemstone.
>
> Our goal is to have a full tool suite that can be parametrized by
> environments (so that
>
> we can compile code in other space, or compile other code inside pharo).
>
> I personnally started this effort one decade ago. Now the introduction
>
> of #asClass and friend is simply destroying all our efforts. There was a
> discussion
>
> in the past but we are not listened.
>
> We will
>
> - packaged these extensions in a separate package
>
> - add rules to ban the use of such method in Pharo
>
> - fix all the use (again) to use the correct way to do it.
>
>
> I can understand that for scripting this is easier but it cannot be at
> that cost and impact.
>
> I hope that we will understand but we have to do something else than
>
> fixing code that breaks our effort.
>
>
> Stef, Marcus, Guille and Luc
>
>
>

Re: [Pharo-dev] Command Line Arguments

[philippe.b...@highoctane.be]

there should be a handler name in there.

Like in pharo-ui Pharo.image st somefile.st

st is the handler.
as is eval or config or your own.

Check subclasses of CommandLineHandler including class side.

Phil
On Apr 27, 2016 6:50 PM, "blake watson"  wrote:

> Hi--
>
> I've seen this come up several times (and it's in "Deep") but I can't seem
> to actually make Command Line Arguments work.
>
> If I do (this is under Windows, but I set up a fresh Linux just to ensure
> it wasn't a Windows quirk):
>
> Pharo.exe Pharo4.0image 99
>
> Pharo comes up with "Command line handler failed". I see in the stack
> trace that the "99" comes in as an orderedCollection. And if I do:
>
> Pharo.exe Pharo4.0image 99 100 101
>
> I get an orderedCollection with 99, 100 and 101, which is what I'd expect.
> In fact, it would be perfect if it didn't crash and put those values
> somewhere, like, I don't know, CommandLineArguments' arguments variable? =)
>
> So, I'm obviously not getting something here. How do I make simple parm
> passing work?
>
> Also, I note that:
>
> Pharo.exe 99 100 101
>
> Brings up Pharo with the default image but swallows the 99, which seems
> odd. I'm guessing that it looks for a 99.image and not finding it, ignores
> the parameter and loads the default image. But it'd be smarter at that
> point to put the 99 back, I think.
>
> ===Blake===
>
>

Re: [Pharo-dev] [HELP WANTED] Getting ready for Pharo 5.0 release (CentOS, oldLibC, Nix, ArchLinux, and others)

[philippe.b...@highoctane.be]

Will do the CentOS 6 thing.
And give a shot at CentOS 7. That one may take longer.

Phil
On Apr 27, 2016 3:26 PM, "Esteban Lorenzano"  wrote:

> Hi,
>
> I’m trying to get ready the download page for Pharo 5.0… who should happen
> next monday :)
> So, I create a download page:
>
> http://pharo.org/download-50
>
> and one for linux:
>
> http://pharo.org/gnu-linux-installation-50
>
> For linux, I made
>
> linux general
> centos
> oldLibC
>
> but
>
> 1) I cannot test them
> 2) list is incomplete, we are still missing:
> - ubuntu ppa
> - Nix
> - ArchLinux
>
> Can responsables for those platforms take action and test/prepare packages?
>
> thanks!
>
> Esteban
>
>
>

Re: [Pharo-dev] [Pharo-users] remove unused variables

[philippe.b...@highoctane.be]

Argh.

It is a very cool feature.

Are we going to have to spot around ?

No, please, no...

Phil

On Apr 22, 2016 2:35 AM, "Johan Fabry"  wrote:
>
>
> This was changed somewhere in November by Marcus and Miguel, and it was
intentional, as part of the work on annotations on the AST that enabled
breakpoints. (Breakpoints use the same highlighting mechanism).
>
>> On Apr 21, 2016, at 18:52, Peter Uhnák  wrote:
>>
>> The editor used to inform when there was an unused local variable and
offered to remove it.
>>
>> Is it possible to get this behavior back, or is it a feature regression
with the "new" (this changed some time ago) editor?
>>
>> Thanks,
>> Peter
>
>
>
>
> ---> Save our in-boxes! http://emailcharter.org <---
>
> Johan Fabry   -   http://pleiad.cl/~jfabry
> PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University
of Chile
>

Re: [Pharo-dev] [Pharo-users] GTDebugger shortcuts usability

[philippe.b...@highoctane.be]

Most of the world IDE use function keys for debugging.

Additional benefit: easier for newcomers to use it.

Having the buttons on the top is a pain as the code pane is at the bottom
and requires travels all the time.

Phil

On Apr 17, 2016 4:57 PM, "Peter Uhnák"  wrote:
>
> Well, I've added a startup script for myself... but it would be nice to
have it everywhere by default in some variant...
>
> ~~
> StartupPreferencesLoader default executeAtomicItems: {
> StartupAction
> name: 'Change debugger labels & shortcuts'
> code: [
> GLMMorphicActionRenderer compile: (
> (GLMMorphicActionRenderer>>#render:) sourceCode
> copyReplaceAll: 'setBalloonText: (anAction title'
> with: 'setBalloonText: (anAction title asString'
> ).
> RestartDebugAction compile: 'defaultKeyText
> ^ ''R'''.
> RestartDebugAction compile: 'defaultLabel
> ^ ''Restart'' asText addAttribute: TextEmphasis underlined from: 1 to: 1'.
> ResumeDebugAction compile: 'defaultKeyText
> ^ ''P'''.
> ResumeDebugAction compile: 'defaultLabel
> ^ ''Proceed'' asText addAttribute: TextEmphasis underlined from: 1 to: 1'.
> StepIntoDebugAction compile: 'defaultKeyText
> ^ ''I'''.
> StepIntoDebugAction compile: 'defaultLabel
> ^ ''Into'' asText addAttribute: TextEmphasis underlined from: 1 to: 1'.
> StepOverDebugAction compile: 'defaultLabel
> ^ ''Over'' asText addAttribute: TextEmphasis underlined from: 1 to: 1'.
> StepThroughDebugAction compile: 'defaultLabel
> ^ ''Through'' asText addAttribute: TextEmphasis underlined from: 1 to: 1'.
> ]
> runOnce: true.
> }
> ~~
>
>
>
> On Sat, Apr 16, 2016 at 11:39 PM, Peter Uhnák  wrote:
>>>
>>> Let’s turn this energy into something positive. Please propose a
concrete set of default keybindings that you think would work better. In
this process, please take into account all keybindings that are already
defined in the code editor (it might not be so easy as it appears).
>>
>>
>> As I've said:
>>
>> 1. can we unify the shift vs ctrl+shift nonsense? (I'm using linux btw)
>> 2. can we use the default shortcuts pattern where one of the letters is
underlined?
>>
>> as for the shortcuts themselves, problem is proceed, restart & into
>>
>> proceed: ctrl+shift+p is not taken, so I don't see why it has shortcut
confusing with restart
>> restart: ctrl+shift+r indents, but I'd argue that uniformity is more
important here... indent is just convenience
>> into: ctrl+shift+i is taken (I've never used it, but it maybe it's
important), but we can still use ctrl+shift+n and underline n (point 2)
>>
>> If points 1 & 2 are implemented, then the letter is not as important,
although first letter is always preferable.
>>
>> Peter
>>
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> > On Apr 16, 2016, at 8:37 PM, Peter Uhnák  wrote:
>>> >
>>> > Hi,
>>> >
>>> > I'm getting fed-up with GTDebugger shortcuts since they are
completely random.
>>> >
>>> > Can we have them more meaningful and/or somehow visible?
>>> >
>>> > For now I ended up overriding the labels so I can at least see
them... but doing this is also stupid, because I still have to look at them
since I cannot remember random shortcuts.
>>> >
>>> > 
>>> > ​
>>> > 1. can we unify the shift vs ctrl+shift nonsense? (I'm using linux
btw)
>>> > 2. can we use the default shortcuts pattern where one of the letters
is underlined?
>>> >
>>> > Peter
>>>
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>>
>>> "Value is always contextual."
>>>
>>>
>>>
>>>
>>>
>>
>

Re: [Pharo-dev] new pharo cheatsheet

[philippe.b...@highoctane.be]

On Apr 9, 2016 9:54 AM, "olivier auverlot" 
wrote:
>
> I think that it could be interesting to use it also  on a simple HTML
page for the Pharo web site. This document can be put in the main menu
("Beginners" ?) just before "Documentation".
>
> It's really cool to have a synthesis document for the newcomers.

I still have a little Squeak booklet that we could redo for Pharo. It was
very useful when I was learning.

Phil
>
> 2016-04-09 8:09 GMT+02:00 Ben Coman :
>>
>> On Sat, Apr 9, 2016 at 6:16 AM, Damien Pollet 
wrote:
>> > On 8 April 2016 at 22:57, Sven Van Caekenberghe  wrote:
>> >>
>> >> Since we are simpler and more logical, a cheat sheet should not
confuse
>> >> people by describing what we are not.
>> >
>> >
>> > I beg to disagree. "Simpler and more logical" is just your biased
point of
>> > view; fact is, zero-based indexing is just more widespread in
programming
>> > languages.
>> >
>> > I would be happy to be proven wrong about that, but I seriously doubt
most
>> > people that come to Smalltalk have never been exposed to programming
before.
>> > It's not unreasonable to assume that they've started programming in
any one
>> > of the most popular languages these days, and that that language is
>> > zero-indexed. So mentioning that in Smalltalk the first element is
indeed at
>> > index 1 is pretty essential, if just to lift the ambiguity.
>>
>> +1.  But to follow Sven's point exactly.  We don't need to say we are
>> "not 0 based", just that we are "1  based".
>>
>> cheers -ben
>>
>

Re: [Pharo-dev] new pharo cheatsheet

[philippe.b...@highoctane.be]

On Apr 9, 2016 8:11 AM, "Ben Coman"  wrote:
>
> On Sat, Apr 9, 2016 at 6:16 AM, Damien Pollet 
wrote:
> > On 8 April 2016 at 22:57, Sven Van Caekenberghe  wrote:
> >>
> >> Since we are simpler and more logical, a cheat sheet should not confuse
> >> people by describing what we are not.
> >
> >
> > I beg to disagree. "Simpler and more logical" is just your biased point
of
> > view; fact is, zero-based indexing is just more widespread in
programming
> > languages.
> >
> > I would be happy to be proven wrong about that, but I seriously doubt
most
> > people that come to Smalltalk have never been exposed to programming
before.
> > It's not unreasonable to assume that they've started programming in any
one
> > of the most popular languages these days, and that that language is
> > zero-indexed. So mentioning that in Smalltalk the first element is
indeed at
> > index 1 is pretty essential, if just to lift the ambiguity.
>
> +1.  But to follow Sven's point exactly.  We don't need to say we are
> "not 0 based", just that we are "1  based".

And we do not need to know most of the time since we have a pretty decent
collection API. Or for matrixes for that matter.

Phil
>
> cheers -ben
>

Re: [Pharo-dev] TxText model

[philippe.b...@highoctane.be]

On Apr 4, 2016 4:24 PM, "Sven Van Caekenberghe" <s...@stfx.eu> wrote:
>
>
> > On 04 Apr 2016, at 16:02, philippe.b...@highoctane.be <
philippe.b...@gmail.com> wrote:
> >
> > Is TxText part of the image?
>
> Try (in 5.0):
>
> TxViewContainer exampleOneLineEditor.
>
> TxViewContainer editText: 'Philippe Back'.

Thx Sven. I'll try that out.

Phil
>
> Sven

Re: [Pharo-dev] TxText model

[philippe.b...@highoctane.be]

On Apr 4, 2016 3:54 PM, "Igor Stasenko"  wrote:
>
>
>
> On 4 April 2016 at 16:41, Stephan Eggermont  wrote:
>>
>> On 04-04-16 14:49, Igor Stasenko wrote:
>>>
>>> Oh, and aside all of that.. Making a full-fledged word processor is not
>>> just a regular engineering task. You need an expert of publishing,
expert
>>> in fonts and typography. That's right from the beginning.
>>> And i am not that expert in this domain(s).
>>> So, next time, when we start talking about things like page layouts,
>>> columns, margins, tabs, references and other stuff, first find an expert
>>> who will be able to transform these terms into technical requirements.
>>> If you think it so simple, it is not: because all those terms came from
>>> paper-publishing domain, that existed even before first computer came to
>>> existence.
>>> The capabilities of TxText and whether it will be capable to handle well
>>> complexities of full-fledged word processing features, at this point,
>>> without having an expert is nothing but just a speculation.
>>
>>
>> I know enough about typesetting and producing technical documentation.
>>
> And i have no idea what typesetting means. I can only guess , since it is
compound from familiar 'type' and 'setting' words.
> And technical documentation.. now i start having a headache :)

Is TxText part of the image?
Any configuration?

Phil
>
>>
>> Stephan
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.

Re: [Pharo-dev] TxText model

[philippe.b...@highoctane.be]

On Apr 4, 2016 3:03 PM, "Igor Stasenko"  wrote:
>
>
>
> On 4 April 2016 at 15:44, Thierry Goubier 
wrote:
>>
>>
>>
>> 2016-04-04 14:24 GMT+02:00 Igor Stasenko :
>>>
>>>
>>>
>>> On 4 April 2016 at 14:28, Thierry Goubier 
wrote:



 2016-04-04 13:18 GMT+02:00 Stephan Eggermont :
>
> On 04-04-16 11:58, Igor Stasenko wrote:
>>
>> Apart from being 'cool to have', full-fledged word processing is not
a thing, that you dealing with on a daily basis in environment, like Pharo.
>
> I'm sure that is the case for you. I wonder if that is the case for
many Pharo users.
> AFAIK there are a lot of pillar users.


 If it is for Pillar, then you don't really need a full-fledged, paper
oriented layout engine. A web-like layout environment is probably enough,
and much less costly to build.

>>>
>>> Now count, how much world-wide resources are dedicated to web-based and
browser-based technology development and compare with our resource base. I
think it is foolish to set an unrealistic goals.
>>
>>
>> I think that if we didn't have unrealistic goals, we wouldn't be in that
community :)
>>
>>>
>
> For me the problem with the TxText model is that it blocks the
possibility of doing
> that later, if and when there is enough development capacity to
invest in this.


 There is enough technology in the Pharo universe to do it (or at least
something approaching). Sometimes, what you need is the ideas / the
rationale from a project to do it. And I do believe TxText has some of it,
even if you consider that TxText can't be extended to do it (and I'll
consider that you are right on this).

 Now, it's on nobody's roadmap, so it may take a while to emerge (if it
does at all).

>>> Last time, i installed LaTex package on my mac, it took maybe hour or
so.. About 1Gb of files, tools, compilers, GUI, text editors..
>>> Now think, how much years it would take to get remotely close to such
level of development? And where are those people or money that would allow
us to think this is viable path and we should throw everything into it to
get there?
>>
>>
>> Have you really looked into what is the core of the TeX algorithm? The
fact that an interactive version of it was done multiple times in history?
(Self / InterViews to cite the ones I know and have used)
>>
>>>
>>> It is nice to dream time to time, but let us be realistic.
>>
>>
>> I'd say that we have an environment where we can dream; where
reinventions can be done at low cost (or at lower cost than others), that
we can even afford to be wrong and throw a project away. Otherwise we
wouldn't have Athens / TxText / GT ...
>>
>> Mind you, I'm not asking you to do it :) I simply know that some of
TxText stuff is usable in that context. And that given the goal, shortcuts
are possible.
>>
>
> But do you realising that we talking here about different scales of
things?
> Let me drive an analogy:
> - you found an engineer that created a rocket engine in his garage.
> Engine is perfect, stable, works well etc etc etc..
> And you asking him:
> - can we fly to the Moon tomorrow?
>
> Huh?
>
> Okay, if you find specialist, who can plan the mission, find the producer
of solar panels, find specialist of long range communications, find
specialists of long-range observations to determine the landing site, find
god know how many other specialist and experts in various areas, only then
you could possibly find and answer to your question.
> But asking such question to just a rocket engine specialist.. is just
foolish.
>
>

Is there a doc explaining TxText somewhere?

One of first things I wanted to do in Pharo (was 1.2 or 1.3 at the time)
was to have text with clickable links, pictures etc.
And not in a web page.

So, I ended up in ParagraphEditor, Text attributes etc.

I still want to make that work and I think that TxText is suitable from
what I saw.

Any pointers?

Phil

>>
>> Regards,
>>
>> Thierry
>
>
>
>
> --
> Best regards,
> Igor Stasenko.

Re: [Pharo-dev] Pharo Days 2016 Photos and Video

[philippe.b...@highoctane.be]

Very good way to start the week indeed!

Phil
On Apr 4, 2016 9:17 AM, "Yuriy Tymchuk"  wrote:

> Good morning everyone!
>
> I think that it’s a nice way to start the new week by viewing photos from
> Pharo Days 2016: https://goo.gl/photos/orgTn4C1bSeqf6fy5.
> Additionally if someone wants to get a quick impression of the conference,
> now there is a video for that: https://youtu.be/eHKtxgbuLSg.
>
>
> Have a great week.
> Cheers!
> Uko
>

Re: [Pharo-dev] Fwd: Squeak 5 on Raspberry Pi

[philippe.b...@highoctane.be]

yes!

Maybe a solid core with a layer of fast evolving things.

That's the model for Hortonworks now. A stable Hadoop core for stability
and fast updates for things like Spark.

Phil
On Mar 25, 2016 6:19 PM, "Hilaire"  wrote:

> Not exactly related to Announcement, but I remember when I first port
> DrGeo to Squeak (at that time Pharo did not exist) I used a lot of
> change/update when objects in the canvas changed. It was terribly slow,
> and later opted for a top-down update in the list of object.
>
> So some sometime what look like a cool stuff (decoupled objects) is just
> a drag.
>
> Regarding optimizing, I share my opinion here months ago, I think Pharo
> need consolidation releases: no new features, only bugs fix and speed
> improvement. There are enough new features in Pharo for a couple of
> years, but the product need to *be* solid and *feel* solid.
>
> Hilaire
>
> Le 25/03/2016 12:33, Stephan Eggermont a écrit :
> > On 25-03-16 11:49, Nicolai Hess wrote:
> >> Morphic drasticallly slower ? I would expect morphic code is mostly
> >> the same in pharo and squeak. If pharo is slower, this is a good
> >> starting point for optimising. Can you gives some hints?
> > I do not have the impression that morphic is so much slower.
> > We had/have a problem of too many announcements being send and
> > too many redraws happening.
> >
> > Stephan
> >
> >
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>

Re: [Pharo-dev] feedback from yet another student presentation

[philippe.b...@highoctane.be]

And that woukd be a nice thing to hack on during PharoDays.
On Mar 11, 2016 9:22 AM, "philippe.b...@highoctane.be" <
philippe.b...@gmail.com> wrote:

> STH can be fixed. This is more like some data problem.
>
> Who can look at the system to identify issues? Is this a Mongo issue?
>
> Phil
> On Mar 11, 2016 8:17 AM, "Serge Stinckwich" <serge.stinckw...@gmail.com>
> wrote:
>
>> On Fri, Mar 11, 2016 at 8:08 AM, stepharo <steph...@free.fr> wrote:
>> >
>> >
>> > Le 10/3/16 22:14, Alexandre Bergel a écrit :
>> >>>
>> >>> - it was realy hard to register a project on smalltalkhub just
>> after
>> >>> we created an account.
>> >>> This already happened to me during the open-devs.
>> >>> So this is a really big show stopper for the mooc. Because people will
>> >>> gave up just after the first lecture :(
>> >>
>> >> The situation will be much easier I hope once git is well supported…
>> >
>> >
>> > But will we have to answer 100 of problems during the mooc?
>> > And if people drop after just because they cannot save their code as we
>> say
>> > it :(
>>
>> Yes this is real annoying problem ... Maybe you can ask Gemstone to
>> support the MOOC
>> with a dedicated ss3 instance (or use ss3).
>>
>> --
>> Serge Stinckwich
>> UCBN & UMI UMMISCO 209 (IRD/UPMC)
>> Every DSL ends up being Smalltalk
>> http://www.doesnotunderstand.org/
>>
>>

Re: [Pharo-dev] feedback from yet another student presentation

[philippe.b...@highoctane.be]

STH can be fixed. This is more like some data problem.

Who can look at the system to identify issues? Is this a Mongo issue?

Phil
On Mar 11, 2016 8:17 AM, "Serge Stinckwich" 
wrote:

> On Fri, Mar 11, 2016 at 8:08 AM, stepharo  wrote:
> >
> >
> > Le 10/3/16 22:14, Alexandre Bergel a écrit :
> >>>
> >>> - it was realy hard to register a project on smalltalkhub just
> after
> >>> we created an account.
> >>> This already happened to me during the open-devs.
> >>> So this is a really big show stopper for the mooc. Because people will
> >>> gave up just after the first lecture :(
> >>
> >> The situation will be much easier I hope once git is well supported…
> >
> >
> > But will we have to answer 100 of problems during the mooc?
> > And if people drop after just because they cannot save their code as we
> say
> > it :(
>
> Yes this is real annoying problem ... Maybe you can ask Gemstone to
> support the MOOC
> with a dedicated ss3 instance (or use ss3).
>
> --
> Serge Stinckwich
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> Every DSL ends up being Smalltalk
> http://www.doesnotunderstand.org/
>
>

Re: [Pharo-dev] [Pharo-users] Little how to

[philippe.b...@highoctane.be]

Isn't Boardician usable?
http://forum.world.st/Boardician-board-game-framework-td4814794.html
On Mar 5, 2016 10:19 AM, "stepharo"  wrote:

> So cl, it was on my todo with my son.
> --- this is really true, he came and told me I want to build my own game...
> And we do not have a game framework in our community --- at least one that
> I understand.
> So I was looking at Ruby or JS :(
>
> And clement show me the link and how he extracted the png.
> So we will do that this afternoon and add this as a challenge for the mooc
> I should have got faster :).
>
>
> Le 3/3/16 22:58, Tudor Girba a écrit :
>
>> Hi,
>>
>> I wrote a little post with a how to extract sprites from a larger png
>> file:
>> http://www.humane-assessment.com/blog/extracting-sprite-from-png
>>
>> Cheers,
>> Doru
>>
>>
>> On Mar 3, 2016, at 9:23 AM, stepharo  wrote:
>>>
>>> Hi guys
>>>
>>> for the mooc I would like have a list of how to that students should
>>> look in the system and implement.
>>> The idea is to show to the participants that Pharo is open and that they
>>> can find information.
>>> For example,
>>> - extracting a sprite from a png file
>>> - access a time service of the web
>>>
>>> Now I would love to get your ideas and their solution.
>>>
>>> Stef
>>>
>>>
>>>
>>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Beauty is where we see it."
>>
>>
>>
>>
>>
>>
>>
>
>

Re: [Pharo-dev] A question about the Dark Theme main background color

[philippe.b...@highoctane.be]

Darcula for everyone! Even Netbeans has it now!

On Mar 3, 2016 3:02 PM, "kilon.alios"  wrote:
>
> I also prefer the darker one , though I use my own personal blue theme.
>
>
>
> --
> View this message in context:
http://forum.world.st/A-question-about-the-Dark-Theme-main-background-color-tp4882265p4882326.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
Nabble.com.
>

Re: [Pharo-dev] Pharo Days 2016 Registration is open

[philippe.b...@highoctane.be]

Working on it.

Some more pictures
http://www.exozt.be/?page_id=6
On Mar 2, 2016 7:24 PM, "Peter Uhnák"  wrote:

> Is there some list of recommended hotels like there was last year?
>
> Peter
>
> On Wed, Mar 2, 2016 at 5:34 PM, stepharo  wrote:
>
>> People from namur told me that the place is really cool.
>> Good choice Phil.
>>
>> Stef
>>
>> Le 2/3/16 09:38, Sven Van Caekenberghe a écrit :
>>
>> Registration for the Pharo Days 2016 is now open !
>>>
>>> We are using EventBrite. You can buy tickets using PayPal and any credit
>>> card. If absolutely necessary, you can opt for an off line payment. Please
>>> register on time.
>>>
>>>http://www.eventbrite.com/e/pharo-days-2016-tickets-22454533113
>>>
>>> For social registration you can use Doodle.
>>>
>>>http://doodle.com/poll/rsc86cqzxbgwr9tr
>>>
>>> Spread the word: http://pharodays2016.pharo.org.
>>>
>>>
>>
>>
>

Re: [Pharo-dev] Hackathon IoT. I used Pharo.

[philippe.b...@highoctane.be]

FWIW I'll be looking at an industrial bigdata project starting next week.

This is solid stuff and I'll be a recommender for some things.

Maybe should we focus on the data feeding side of things. How fast can we
be?

Phil
On Feb 23, 2016 11:07 AM, "Ben Coman" <b...@openinworld.com> wrote:

> There is real business opportunity for "Industrial" Internet of
> Things.  Morphic (and next Block) makes Pharo would make a fantastic
> platform for the HMI (Human Machine Intereface) of a factory or
> machine. And its good reoccurring work, as engineers are *paid* to
> consult on troubleshooting, optimising and modifying the factory
> automation code as factories evolve over time.
>
> Two significant enabling technologies are...
>
> OPC (Open Platform Computing) - This is *the* integration protocol for
> factories. Its the most widely adopted interoperability standard for
> secure, reliable and platform-independent information exchange for
> industrial automation.
>
>   * Over 500 OPC Foundation members and thousands of OPC-compliant products
>  https://opcfoundation.org/members
>
>   * Understanding OPC: Open Connectivity via Open Standards
>
> http://www.automation.com/pdf_articles/Understanding_OPC_Kepware_eBook.pdf
>
> EtherCAT - Ethernet for Control Automation Technology adds real-time
> and other capabilities to classic Ethernet
>
>  * Endorsed by more than 3,000 companies
>  https://www.ethercat.org/en/members.php
>
>  * What are the advantages of EtherCAT over other fieldbus technologies?
> https://www.youtube.com/watch?v=j3j6segCpEc
>
>  * High speed servo control of motors over EtherCAT - simply not
> possible with any other industrial comms protocol
> https://www.youtube.com/watch?v=CXb_m8p3Yt4
>
>  * MCUs and EtherCAT Gear Up for the Industrial Internet of Things.
>
> http://www.digikey.com/en/articles/techzone/2015/aug/mcus-and-ethercat-gear-up-for-the-industrial-internet-of-things
>
>  * The *biggest* advantages is the use of standard ethernet, doing
> away with proprietary hardware and consequent vendor lock in.
>  https://www.youtube.com/watch?v=klxwX_44DcM (stop watching a 5:00)
>
>
> And now these two technology groups are now working together...
>
> https://opcfoundation.org/news/press-releases/opc-foundation-ethercat-technology-group-sign-mou/
>
>
> cheers -ben
>
>
>
> On Tue, Feb 23, 2016 at 3:30 PM, stepharo <steph...@free.fr> wrote:
> > I'm interested too because we Rmod wants to check Pharo as a IoT
> platform in
> > the future
> >
> > Le 22/2/16 15:07, philippe.b...@highoctane.be a écrit :
> >
> > LoRa stuff with sensors etc. Integrated REST apis for that in Pharo.
> >
> > I'll do a writeup on my blog.
> >
> > Lots of opportunities for Pharo in that space.
> >
> > Phil
> >
> > On Feb 22, 2016 2:49 PM, "Serge Stinckwich" <serge.stinckw...@gmail.com>
> > wrote:
> >>
> >> Great ! What did you exactly, I'm interested by details ;-)
> >>
> >> 2016-02-22 14:42 GMT+01:00 p...@highoctane.be <p...@highoctane.be>:
> >> >
> >> >
> http://geeko.lesoir.be/2016/02/22/hackapost-un-hackathon-sur-les-applis-iot-pour-le-service-postal-belge/
> >>
> >>
> >>
> >> --
> >> Serge Stinckwich
> >> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> >> Every DSL ends up being Smalltalk
> >> http://www.doesnotunderstand.org/
> >>
> >
>
>

Re: [Pharo-dev] Hackathon IoT. I used Pharo.

[philippe.b...@highoctane.be]

Sure. I've got a LoRa kit with sensors etc.

API should work but LoRa gateway may be an issue.

I may be able to ask for a pico receiver.

Phil
On Feb 22, 2016 5:25 PM, "Serge Stinckwich" <serge.stinckw...@gmail.com>
wrote:

> On Mon, Feb 22, 2016 at 3:07 PM, philippe.b...@highoctane.be
> <philippe.b...@gmail.com> wrote:
> > LoRa stuff with sensors etc. Integrated REST apis for that in Pharo.
> >
> > I'll do a writeup on my blog.
> >
> > Lots of opportunities for Pharo in that space.
>
> Yes, I think so.
> I would like to push Pharo in this area in the future, especially with
> LoRa sensors. We will organize a meeting for wireless sensors for
> environmental surveillance in May.
> are you interested to present something around Pharo ?
>
> Regards,
> --
> Serge Stinckwich
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> Every DSL ends up being Smalltalk
> http://www.doesnotunderstand.org/
>
>

Re: [Pharo-dev] Hackathon IoT. I used Pharo.

[philippe.b...@highoctane.be]

LoRa stuff with sensors etc. Integrated REST apis for that in Pharo.

I'll do a writeup on my blog.

Lots of opportunities for Pharo in that space.

Phil
On Feb 22, 2016 2:49 PM, "Serge Stinckwich" 
wrote:

> Great ! What did you exactly, I'm interested by details ;-)
>
> 2016-02-22 14:42 GMT+01:00 p...@highoctane.be :
> >
> http://geeko.lesoir.be/2016/02/22/hackapost-un-hackathon-sur-les-applis-iot-pour-le-service-postal-belge/
>
>
>
> --
> Serge Stinckwich
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> Every DSL ends up being Smalltalk
> http://www.doesnotunderstand.org/
>
>

Re: [Pharo-dev] [OT] Open source everything

[philippe.b...@highoctane.be]

Interesting read.

Will take action along these lines.

Phil
On Jan 2, 2016 12:37 PM, "Eliot Miranda"  wrote:

> Happy new year!
>
> http://gu.com/p/3q95q 
>
> _,,,^..^,,,_ (phone)
>

Re: [Pharo-dev] [Pharo-users] Happy new year 2016

[philippe.b...@highoctane.be]

Happy New Year to the Community that makes the tool with the shortest path
between the brain and actual tangible executable results.

I am appreciating it even more now that I have to work with toolchains
requiring lengthy  compilation. How primitive.

Let's make 2016 a great Pharo year.

And see you at PharoDays!
Phil

On Jan 1, 2016 7:55 PM, "Trussardi Dario Romano" 
wrote:
>
>
> > Happy new year to all!
>
> + 1000
>
> >
> > Alexandre
> >
> >
> >> On Jan 1, 2016, at 12:57 PM, stepharo  wrote:
> >>
> >> Hi Pharoers
> >>
> >> I want to thank all of you for making Pharo what it is becoming: a
Really Cool system and community.
> >>
> >> I wish you good health and a lot of business or fun in Pharo :).
> >>
> >> 2016 will see many changes that are planned
> >> to name a few
> >>   - Pharo 5.0 with Spur
> >>   - Pharo 5.0 with 64 bits
> >>   - Bootstrap Pharo in production
> >>   - SDL full integration
> >>   - Git and Package validation
> >>   - A full Mooc on Pharo
> >>   - A couple of cool tutorials
> >> And I'm sure many unexpected project and libraries...
> >>
> >> The consortium should continue to grow so if you are hesitating to
join please do.
> >>
> >> Stef
> >>
> >
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
>
>

Re: [Pharo-dev] AsmJit

[philippe.b...@highoctane.be]

Couldn't we reuse the AsmJIT DSL and generate some C code with Asm
directives through Slang?

And call that C code through FFI?

Seems cleaner and more debuggable.
And could be moved to x64.

Phil

On Dec 16, 2015 6:49 AM, "Clément Bera"  wrote:
>
>
>
> 2015-12-15 20:22 GMT+01:00 Jan Vrany :
>>
>> Hi Esteban, Eliot, Clemont
>>
>> thanks very much for elaborate answer. I'm aware of all what you said
>> (well, most :-), but my actual needs are very low and primitive.
>>
>> All I need now is something that allows me to turn x86_64 assembly
>> into a machine code using a sane Smalltalk API, which I can later copy
>> to VM code space. Nothing more, nothing less :-) I do not fancy
>> spending time writing yet-another-x86-assembler hence my interest in
>> asmjit.
>
>
> As far as I know AsmJIT has stable support for x86 but not x86_64
>>
>>
>> Thanks! Jan
>>
>>
>>
>> On Tue, 2015-12-15 at 18:34 +0100, Clément Bera wrote:
>> > We're getting away from Jan initial question here ...
>> >
>> > I think the point here is that Cog has:
>> > - 2 stable back ends: ARMv5 and x86
>> > - 2 backends stable in the simulator with production planned for ~
>> > April: x64 and MIPS
>> > and Tim is willing to do the ARMv8 backend.
>> >
>> > All the 4, and soon 5, cog back ends are maintained:
>> > - x86 and x64 maintained by Eliot
>> > - MIPS maintained by Ryan
>> > - ARMv5 and soon ARMv8 maintained by Tim
>> >
>> > Each backend requires months of work.
>> >
>> > Do you want to maintain 10 backends instead of 5 ? Do want to spend
>> > time to implement 5 backends or 10 ?
>> >
>> > I don't. Only the x86 backend is duplicated right now in AsmJIT.
>> >
>> > So one idea is to reuse Cog's backends from the image instead of
>> > AsmJIT. To do so, we can use encodings available in the sista
>> > extended instruction set to tell Cog what machine code to generate. A
>> > project named uFFI aims, among other things, at doing this, by
>> > providing a unified interface between the Cog backends and AsmJIT.
>> >
>> >
>> > 2015-12-15 16:43 GMT+01:00 Eliot Miranda :
>> > > Hi Jan,
>> > >
>> > > > On Dec 15, 2015, at 3:06 AM, Jan Vrany 
>> > > wrote:
>> > > >
>> > > > Hi guys,
>> > > >
>> > > > two queations:
>> > > >
>> > > > (i) Is AsmJit going to be developed any more or it's abandoned
>> > > > as well as native boost?
>> > >
>> > > AsmJIT is effectively being abandoned but NativeBoost is not.
>> > >
>> > > The key limitation of AsmJIT is that it was not designed to be
>> > > cross platform; it is effectively an x86 assembler.  As such it's
>> > > use gets in the way of ARM and x86_64 (I am currently getting the C
>> > > version of 64-bit Cog Spur working on x86_64, given that it is
>> > > working in the simulator).
>> > >
>> > > Another limitation is that it doesn't play that well with the VM's
>> > > JIT.  Igor and I never managed to work on integrating it better.
>> > > The VM's job is managing code and Igor's approach was to hack;
>> > > eliminating execution protection in the entire heap, instead of
>> > > extending the support that either the Alien plugin's callback
>> > > support or the JIT's executable method zone provides.  Making the
>> > > entire heap executable is /not/ a sensible approach.
>> > >
>> > > But there is a better way!  A key component of the Sista adaptive
>> > > optimizer/speculative inlined that Clément is currently stabilizing
>> > > (!!) is a set of bytecodes that encode unsafe operations like
>> > > at:put: without bounds, type or store checks.  For example, the
>> > > normal at:put: is about a hundred instructions, checks for
>> > > smallinteger indices, differentiates between byte, 32-but long and
>> > > pointer objects and does a store check. But one of the Sista codes
>> > > for at:put: generates about two instructions, one to adjust the
>> > > index, the other to do the store.  Distaste job is to analyze code
>> > > and inline methods using these unsafe bytecodes where they are
>> > > proven to be safe, hence increasing performance.
>> > >
>> > > Unlike AsmJIT, Sista's unsafe bytecodes are cross platform, and,
>> > > being executed by the VM, can work on an interpreter VM or be
>> > > converted to machine code by the JIT.
>> > >
>> > > So our plan is to extend these bytecodes with ones that support
>> > > marshaling arguments for NativeBoost calls.  Ronie Salgado has
>> > > already extended his lowcode scheme to define these instructions
>> > > and sometime soon (hopefully 2016) we shall rewrite NativeBoost to
>> > > target these bytecodes.
>> > >
>> > > HTH
>> > >
>> > > > (ii)Where can I find latest AsmJit? I'm properly confused:
>> > > >
>> > > > * Is is the one in latest Pharo 4.0 (5.0) image?
>> > > > * Is it the one here: http://smalltalkhub.com/#!/~Pharo/AsmJi
>> > > t ?
>> > > >   (the one in the image seem to be based on completely
>> > > disjunct
>> > > >set of .mcz than those in the 

Re: [Pharo-dev] License agreement - are you kidding me?

[philippe.b...@highoctane.be]

This ensures the legal thing is no bull and that the rights are indeed MIT.
There has been cases of problems and this ensured that lawyers could
quickly sort things out.

Phil
On Dec 7, 2015 7:31 PM, "webwarrior"  wrote:

> It would be logical to make contribution to an open source project easy,
> right?
> Well, in bigger projects some burocracy is inevitable, but usually has some
> valid reasons behind it.
>
> When I made some commits to Spec (while it was on github), it was as easy
> as
> fork->commit->create pull request.
> In Pharo, it's already more complicated: you have to register yourself in
> SmalltalkHub, in fogbugz, in mailing lists. Slices system is also not very
> intuitive. Then CI system spits out some completely unrelated errors.
>
> But OK, I understand that Pharo is unlike, and the team maybe doesn't have
> time to migrate to some integrated bugtracker/repository/whatever.
>
> Then people began asking me of my real name - which is already wierd - why
> would they need it?
>
> And then someone suggested that I must sign license agreement (which is
> also
> wierd - MIT license doesn't demand anything like that).
>
> I looked at that agreeement. It requires you to provide name, address
> (???),
> sgin it and send it via snail mail (WTF???).
>
> No, guys, that is beyond good and evil.
> Either we skip this stupid formality and continue working on the code, or
> I'm out of this.
>
>
>
> --
> View this message in context:
> http://forum.world.st/License-agreement-are-you-kidding-me-tp4865853.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] Java Future

[philippe.b...@highoctane.be]

We do need more ease of integration with other software.

* 64 bit.
* OS Process made easier.
* FFI not requiring a PhD
* Being able to use Pharo with normal text based tools (like mount an image
like a filesystem).
* Full integration with trendy tools. e.g. MongoTalk missing GridFS,
sharding, HA.

These things are moving forward.

I am pissed that Julia got $600 000 and we are struggling due to cash
issues.

We do not miss brainpower. We miss being able to focus on progress because
we can't fund it well enough.

Phil



On Nov 30, 2015 12:21 PM, "Tudor Girba"  wrote:
>
> Hi,
>
> Increasing the community is certainly important, and we welcome any
action that anyone would want to undertake in this direction.
>
> However, talking about the future of Java does not fall in this category.
>
> Cheers,
> Doru
>
>
> > On Nov 30, 2015, at 4:44 AM, EuanM  wrote:
> >
> > We also need to concentrate on building our community.
> >
> > We build a better platform faster if we have more people.
> >
> > We build a more valuable platform if we have a wider range of valuable
> > use cases to target.
> >
> > Unless and until we hit a critical mass of people joining our
> > community, we *need* to spend some of our focus on community-building.
> >
> > Part of great is being able to build things to sufficient completeness
> > *and* keep them in working order over the long haul.   This is easier
> > with more contributors.
> >
> > On 27 November 2015 at 21:27, Tudor Girba  wrote:
> >> Hello everyone,
> >>
> >> Please stop this thread on this mailing list. We need to focus on
building a great platform.
> >>
> >> Cheers,
> >> Doru
> >>
> >>
> >>> On Nov 27, 2015, at 10:05 PM, EuanM  wrote:
> >>>
> >>> First of all - is this true?  Where can we read about it?
> >>>
> >>> I cannot find anything about this at
> >>> https://www.oracle.com/search/press
> >>>
> >>> ===
> >>>
> >>> If Oracle did make this statement, then what people have said so far
> >>> is true.   BUT...
> >>>
> >>> Java got about 40% of its initial momentum from IBM dumping VisualAge
> >>> and putting all their resources into Java.
> >>>
> >>> Oracle are targetting this move at IBM more than anyone else.
> >>>
> >>> IBM will start to think about how to migrate from Java - as Oracle are
> >>> telling them they will have to.  (It's OUR bat and its OUR ball, and
> >>> no-one else can play with it.  Not even the Java Community).  And
> >>> IBM's coders do not pay for Java, Eclipse users do not pay for Java. I
> >>> expect the licence-fee income for JREs is small.
> >>>
> >>> Oracle are doing one of two things - announcing that Java is for sale
> >>> to device providers - phones (Google is the obvious buyer) or the
> >>> impending Internet of Things (which was what Java was designed for
> >>> originally) or announcing that no-one making an internet of things
> >>> offering should consider Java.
> >>>
> >>> Yes, things live on and on in a kind of zombie state.  So yes, things
> >>> live on as long as their ecosystem does.  And they gently wither and
> >>> their ecosystem withers is a long slow drawn out spiral.  Which is why
> >>> we still have Cobol.
> >>>
> >>> People and organisations tend to move from one technology to another
> >>> in an incremental fashion.  Swapping a little bit here, and a little
> >>> bit there.
> >>>
> >>> The new target platforms are ones which
> >>> 1) look like they have longevity, and
> >>> 2) have a migration pathway that provides incremental steps.
> >>>
> >>> Offering a compelling  advantage is good - but only if the steps 1)
> >>> and 2) are catered to.
> >>>
> >>> IBM VisualAge Smalltalk is still robust, commercially available
> >>> software, and VisualStudio and Gemstone continue to represent
> >>> Smalltalk out to the big world of corporate development.
> >>>
> >>> So that's a start.
> >>>
> >>> Say only 5% of the Java world moves away from Java each year, as a
> >>> result of this announcement.
> >>>
> >>> We *should* wish to take advantage of this announcement.
> >>>
> >>> After all, think what difference having even 0.01% of the world's Java
> >>> coders moving to Smalltalk would make.How could we help that
> >>> happen?
> >>>
> >>> Think what it would be like to have thought-leaders like Kent Beck and
> >>> Ward Cunningham back in the Smalltalk fold.  How could we help that
> >>> happen?
> >>>
> >>> Think what it would be like to get back all the universities who moved
> >>> from teaching OO concepts using Smalltalk into teaching them via Java.
> >>> We now know almost all the ones using Smalltalk as a teaching language
> >>> by name.  Does anyone know even how many universities teach OO via
> >>> Java?What would it be like if 5% of those universities moved to
> >>> Smalltalk each year.   How could we help that happen?
> >>>
> >>> Next - do we have any big brained thinkers who can see specific ways
> >>> we 

Re: [Pharo-dev] Digest from slack to the mailing list?

[philippe.b...@highoctane.be]

And I've not been looking at Slack that much.

Digest would be we nice indeed.

Phil
On Nov 30, 2015 4:53 AM, "EuanM"  wrote:

> And of course, we can stop doing it manually once threading arrives.
>
> On 30 November 2015 at 03:52, EuanM  wrote:
> > I have been talking to the Slack dev team and they assure me that
> > threading is on its way - as a priority.
> >
> > I am happy to manually curate threads if someone gets a 24hour dump to
> > log files working.
> >
> > The best way to do this would be to have teams of curators per
> > channel, each doing a little curation periodically on a rota per
> > channel basis.
> >
> > This is an ideal task for people still getting up to speed with Pharo
> > internals.  It is a great way to be exposed to stuff you don't
> > understand, and put your mind around it.
> >
> > This provide a starter slope for future contributors.
> >
> > On 23 November 2015 at 08:14, Yuriy Tymchuk 
> wrote:
> >> The problem is, that it is not that easy to create a “digest” from
> Slack, as there is no kind of grouping. Either you have to detect similar
> words in discussion, or you have to simply export everything. I don’t know
> whether it makes sense to just compose a huge email of all discussions, but
> we can try to do that.
> >>
> >> Cheers.
> >> Uko
> >>
> >>> On 23 Nov 2015, at 00:21, EuanM  wrote:
> >>>
> >>> I agree - if we can have each 24 hours of chat archived to somewhere
> >>> that provides a free-text search, that would be very good.
> >>>
> >>> Up until now, I've been grabbing, editting and posting chats I find of
> >>> interest and importance to me.  And it seems to lend itself to design
> >>> discussions.  What it's not very good at, atm, is discussion
> >>> threading.  It would be great to be able to set your typing as
> >>> belonging to a thread., so that when it get sucked out and archived
> >>> that the threads were segregated.
> >>>
> >>> Does someone have a server that could receive a text dump of all
> >>> recent Slack messages every 12 (or 24, or 6) hours, and then make it
> >>> available for indexing by Google et al, and querying (via the search
> >>> engines) by our dev base?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On 22 November 2015 at 13:57, Dimitris Chloupis 
> wrote:
>  Just to clear something up , because I see people in slack saying
> goodbye,
>  or "I cant reply right now I have something to do" . Slack is not
> just a
>  real time chat, it keeps messages inside a history of 10 thousand
> messages.
>  So that means you can log in Slack at any time and not lose a
> message. There
>  is no reason for you to be online all time, no reason to say goodbye,
>  goodmorning , goodafternoon. You can come and go as you please the
> exact
>  same way as the mailing list.
> 
>  The problem arises when we exceed 10k messages, the old ones get lost
> and I
>  think having a place to store them is a good idea.
> 
>  Also what is important is in the eye of the beholder, for example I
> dont
>  care about any discussion about web development , its just does not
> interest
>  me or database coding or many other things. I have learned to filter
> out the
>  messages I dont care about in the mailing list and just reject them.
> Slack
>  is same story, I quickly glance through its history and I can search
> the
>  messages that interest me using the search bar , I can star messages
> that I
>  want to keep, and I can comment on existing messages / code snippets
> which
>  create a thread about that message.
> 
>  In the end its impossible to keep the community in one place but to
> have a
>  central hub that collects all the little gems can be quite useful.
> 
>  On Sun, Nov 22, 2015 at 3:46 PM stepharo  wrote:
> >
> > Yes this would be good.
> > People should understand that important discussions should be via the
> > mailing-list.
> > Emails are good because you can consume them the way you want.
> > I simply cannot be connected all the time. So emails are good
> because I
> > can process them
> > when I decide.
> > Slack is good for more interactive session around debugger and things
> > like that.
> >
> > Stef
> >
> >
> > Le 21/11/15 18:05, Stephan Eggermont a écrit :
> >> Should we have a digest from slack to a mailing list?
> >> We are already losing messages
> >>
> >> Stephan
> >>
> >>
> >>
> >
> >
> 
> >>>
> >>
> >>
>
>

Re: [Pharo-dev] Random forest in Pharo

[philippe.b...@highoctane.be]

I guess you aren't doing lots of random forests.

RFs training is the best way to turn my PC into a heater.

Phil

Phil
Le 15 oct. 2015 14:19, "Esteban Lorenzano" <esteba...@gmail.com> a écrit :

> yeah but if this is a special case there is no problems on doing FFI
> bindings and using an external library.
> Precisely for that is FFI.
>
> not that we have to integrate everything into the image :)
>
> but… I would not be so fast in assume pharo performance will not be
> enough. Unique form to know it is to do it and then see how you can
> optimise, if needed :)
>
> Esteban
>
> On 15 Oct 2015, at 09:51, stepharo <steph...@free.fr> wrote:
>
> We do not want to be bound to install and maintain connection with fifteen
> different libs.
>
> Stef
>
> Le 14/10/15 18:01, philippe.b...@highoctane.be a écrit :
>
> Not sure you would get enough performance on Pharo per se. Xe may be
> better off leveraging a multicore enabled external lib. Like caret and doMC
> on R.
> Le 14 oct. 2015 17:49, "Serge Stinckwich" <serge.stinckw...@gmail.com> a
> écrit :
>
>> I don't think so.
>>
>> I followup your message on SciSmalltalk mailing-list.
>> This is something that might interested us ;-)
>>
>>
>>
>> On Wed, Oct 14, 2015 at 4:54 PM, Damien Cassou < <damien.cas...@inria.fr>
>> damien.cas...@inria.fr> wrote:
>> > Hi,
>> >
>> > did anyone implement a Random Forest algorithm in Pharo?
>> >
>> > https://en.wikipedia.org/wiki/Random_forest
>> >
>> > --
>> > Damien Cassou
>> > http://damiencassou.seasidehosting.st
>> >
>> > "Success is the ability to go from one failure to another without
>> > losing enthusiasm." --Winston Churchill
>> >
>>
>>
>>
>> --
>> Serge Stinckwich
>> UCBN & UMI UMMISCO 209 (IRD/UPMC)
>> Every DSL ends up being Smalltalk
>> http://www.doesnotunderstand.org/
>>
>>
>
>

Re: [Pharo-dev] Random forest in Pharo

[philippe.b...@highoctane.be]

I would see the FFI integration being much more approachable.

In R, Python, Tcl, and now Java with JNA things are going nicely.

Why is it a pain on our platform and why insist on doing all in Pharo?

This is holding us back.

Pharo is super strong at some things.

We just do not need it to be redoing everything when good business is at
hand and industry standard libs available.

A reason why we try to use libgit2 I guess. Something external.

Phil
Le 15 oct. 2015 14:29, "philippe.b...@highoctane.be" <
philippe.b...@gmail.com> a écrit :

> I guess you aren't doing lots of random forests.
>
> RFs training is the best way to turn my PC into a heater.
>
> Phil
>
> Phil
> Le 15 oct. 2015 14:19, "Esteban Lorenzano" <esteba...@gmail.com> a écrit :
>
>> yeah but if this is a special case there is no problems on doing FFI
>> bindings and using an external library.
>> Precisely for that is FFI.
>>
>> not that we have to integrate everything into the image :)
>>
>> but… I would not be so fast in assume pharo performance will not be
>> enough. Unique form to know it is to do it and then see how you can
>> optimise, if needed :)
>>
>> Esteban
>>
>> On 15 Oct 2015, at 09:51, stepharo <steph...@free.fr> wrote:
>>
>> We do not want to be bound to install and maintain connection with
>> fifteen different libs.
>>
>> Stef
>>
>> Le 14/10/15 18:01, philippe.b...@highoctane.be a écrit :
>>
>> Not sure you would get enough performance on Pharo per se. Xe may be
>> better off leveraging a multicore enabled external lib. Like caret and doMC
>> on R.
>> Le 14 oct. 2015 17:49, "Serge Stinckwich" <serge.stinckw...@gmail.com> a
>> écrit :
>>
>>> I don't think so.
>>>
>>> I followup your message on SciSmalltalk mailing-list.
>>> This is something that might interested us ;-)
>>>
>>>
>>>
>>> On Wed, Oct 14, 2015 at 4:54 PM, Damien Cassou <
>>> <damien.cas...@inria.fr>damien.cas...@inria.fr> wrote:
>>> > Hi,
>>> >
>>> > did anyone implement a Random Forest algorithm in Pharo?
>>> >
>>> > https://en.wikipedia.org/wiki/Random_forest
>>> >
>>> > --
>>> > Damien Cassou
>>> > http://damiencassou.seasidehosting.st
>>> >
>>> > "Success is the ability to go from one failure to another without
>>> > losing enthusiasm." --Winston Churchill
>>> >
>>>
>>>
>>>
>>> --
>>> Serge Stinckwich
>>> UCBN & UMI UMMISCO 209 (IRD/UPMC)
>>> Every DSL ends up being Smalltalk
>>> http://www.doesnotunderstand.org/
>>>
>>>
>>
>>

Re: [Pharo-dev] Random forest in Pharo

[philippe.b...@highoctane.be]

Not sure you would get enough performance on Pharo per se. Xe may be better
off leveraging a multicore enabled external lib. Like caret and doMC on R.
Le 14 oct. 2015 17:49, "Serge Stinckwich"  a
écrit :

> I don't think so.
>
> I followup your message on SciSmalltalk mailing-list.
> This is something that might interested us ;-)
>
>
>
> On Wed, Oct 14, 2015 at 4:54 PM, Damien Cassou 
> wrote:
> > Hi,
> >
> > did anyone implement a Random Forest algorithm in Pharo?
> >
> > https://en.wikipedia.org/wiki/Random_forest
> >
> > --
> > Damien Cassou
> > http://damiencassou.seasidehosting.st
> >
> > "Success is the ability to go from one failure to another without
> > losing enthusiasm." --Winston Churchill
> >
>
>
>
> --
> Serge Stinckwich
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> Every DSL ends up being Smalltalk
> http://www.doesnotunderstand.org/
>
>

Re: [Pharo-dev] Autonomous Shark-Monitoring Drone

[philippe.b...@highoctane.be]

Maybe you want to connect with the people at Fleye.

Their drone is quite close to what you have in mind.
Le 7 oct. 2015 17:55, "Eliot Miranda"  a écrit :

> Dear Friends and Colleagues,
>
> as you may know, Sharks, as apex predators, are vital to maintaining
> healthy marine ecosystems, and at the same time, their populations are
> plummeting due to human actions.  It is estimated for example that the
> population of pelagic oceanic white tip sharks is reducing by 17% per year
> [1] and I've heard (can't find a reference) that populations in the eastern
> indian/western pacific are at 1% of normal levels.  Such reductions in
> populations create "trophic cascades" that produce wide-ranging changes in
> populations of different species all the way down the food chain [2].  And
> the marine ecosystem is a key source of human nutrition; it comprises
> between 13% and 17% of global human protein intake [3].
>
>   As you may also know, there is currently a shark attack crisis in New
> South Wales [4].  While most people in the region oppose killing sharks in
> response to the crisis, existing solutions, netting and culling reduce
> those same threatened populations of sharks upon which the sustainability
> of marine food supply d ecosystems depend [5], and are arguably ineffective
> [6].  Apparently the most successful approach at avoiding attacks is the
> use of human spotters, as used in Cape Town, where people in tall towers
> scan the sea close to shore [6].
>
>   But please watch this Youtube video
>  [7] from Pismo Beach,
> California.  The shark is spotted at about 1:20 into the video.  This
> drone, a phantom 3, is sending live video back to the operators, who are
> using remote control.  What we can see from this video is that the point of
> view of drones is far superior to that of spotters.
>
>   My first thought is that autonomous drones could provide a cheap and
> scalable solution to patrolling beaches to prevent shark attacks.  I expect
> that processors like the Pi 2 have easily enough processing power to both
> plan and execute search patterns along beaches, and perform the image
> recognition necessary to reliably detect potentially dangerous sharks.  A
> drone might also be able autonomously to visit surfers and swimmers near to
> the shark and warn them, either by some signal such as flashing red LEDs or
> an audible message (language issues notwithstanding).  The drone would have
> to be able to identify swimmers and surfers in the water (not easy; sharks
> confuse seals and surfers all the time), but computing an optimal route to
> visit suspected swimmers should be relatively easy :-).
>
>   I imagine that sooner or later it will be possible to construct cheap
> rugged solar powered docking/charging shelters that drones could depart
> from and return to, to charge and shelter from the elements after patrols.
> Satellite communications could provide status reports for maintenance.
>
>   My second thought is that as a community, we probably have all the
> necessary expertise to construct a working prototype that at least
> demonstrates feasibility.  Such a prototype would have to be able to fly
> above the ocean along a beach under its own control for a useful period of
> time, at least  15 minutes, and demonstrate that it can identify a shark in
> the water (we could use a rubber shark
>  for testing ;-) ).
>
> Our community includes people doing image recognition with the Pi, radio
> control experts, users of 3D printers, and some exceptional programmers.
> If a small, strong group could be formed with the relevant expertise we may
> be able to develop a prototype in a short enough time frame to be
> relevant.  Of course, availability of time is a big issue. I couldn't
> contribute more than a few hours a week.  But nothing ventured, nothing
> gained.  So I'm writing this message to the Squeak and Pharo communities,
> and bcc'ing a few friends I know that have relevant expertise to ask for
> two things; first, for good information on scoping out the project,
> possible technologies, power budgets, costs, what is available
> off-the-shelf (both in hardware and known algorithms) and what we would
> need to construct ourselves, and second, for volunteers.  Who among us are
> really excited by this project, have relevant expertise and are motivated
> to make a contribution?
>
>
> [1] www.sharkadvocates.org/cites_4sharks_owt_fact_sheet.pdf
> [2] http://www.globalshark.ca/pressmaterial/cascading/fig1_web.pdf
> [3] http://www.who.int/nutrition/topics/3_foodconsumption/en/index5.html
> [4] http://www.bbc.com/news/world-australia-34398516
> [5]
> http://www.theguardian.com/environment/2015/sep/29/shark-hit-australian-community-opposes-cull-research-finds
> [6] http://www.nonswsharkcull.net/latestnews/tag/shark_spotting/
> [7] https://www.youtube.com/watch?v=q2U3gjwJfS4
>
>
>
> 

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[philippe.b...@highoctane.be]

Le 1 oct. 2015 13:21, "Damien Cassou"  a écrit :
>
>
> Alexandre Bergel  writes:
>
> > Why not having just one folder level? As we would have in any other
> > language?
>
> that's not true. In java, a Java path typically looks like:
>
> project/src/main/java/org/apache/project/base/model/MyModel.java

Same boat for PHP when using frameworks like ZendFramework2.

Namespaces are in, along with composer modules etc. So looong pathes.

Phil
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Success is the ability to go from one failure to another without
> losing enthusiasm." --Winston Churchill
>

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[philippe.b...@highoctane.be]

Le 28 sept. 2015 04:29, "Ben Coman"  a écrit :
>
> On Sun, Sep 27, 2015 at 8:59 PM, Esteban Lorenzano 
wrote:
> > Hi,
> >
> > I’ve been using git for all my projects since more than one year now,
and frankly I found it really good… and the pull request mechanism is
unbeatable.
> > Now, what I do believe is that we need to improve a couple of things:
> >
> > 1) filtree format is not good while working on teams (which is the
power of git, after all). Merging is a pain and the merge driver provided
by Thierry is just a patch, not a real alternative.
> > 2) double commit is annoying.
> >
> > We have a decent solution for (2), gitfiletree but is not working fine
in windows (and that’s mandatory). I would like a community push here to
make it work fine.
> > Once is working, I would like to replace the OSProcess usage with
actual libgit2. As far as I understand, this is already possible but we
hadn’t commit time to make it possible (and I would put it as a secondary
goal: first make it work with what we have, then use the library).
>
> Would moving to libgit2 bypass the problem with stdio?
>
> > Now the filetree format has problems merging because it stores some
metadata that we do not really need. The origin of this is the fact that is
using git as “just another interchangeable repository for monticello”. IMHO
while this was desirable for start, is not a good solution now. We do not
need that information at all.
> > I worked in a replacement for filetree and as a file format it works
fine… is just a variation who does not stores the not-needed information
and relies on STON to manage the one we actually need.
>
> I have a vague recollection that the problem was a particular file
> where data changed each commit and having the idea that this might be
> solved by: each commit writing metadata to a different file e.g.
> .metadata, and Monticello knows to pick up the highest numbered
> metadata.
>
>
> > After, we can build the actual tools we need. But with that working we
will see a lot clearer what we actually need to do :)
> >
> > So I would do a “call for pushing” and ask community to spend some time
making it work properly.
> >
> > cheers,
> > Esteban
> >
> >
> >> On 27 Sep 2015, at 13:43, stepharo  wrote:
> >>
> >> Alex do you know git?
> >> Because to me git is **really** complex. I do not talk about add push
commit but rebase remote
>
> Git is very flexible which implies complexity for newcomers to it.
> What is required on top of git is a "well defined" workflow.I see
> sometimes on this mail-list that people design their tools for
> flexibility since they don't want to *impose* a workflow on people,
> which is a commendable philosophy, but slows adoption by newcomers.
> It may be useful to define "this is *the* way its done here" , with
> the standard proviso that there may be missteps that need to be tuned.

Currently working in a distributed team with multiple companies. We use git
and also Phabricator for reviews which is really great.

I cant think of *not* using a DVCS and features like git rebase in such an
environment.

Phil

>
> cheers -ben
>
>
> >> Did you try to use sourcetree (the UI for git) to understand what I
mean?
> >> So we cannot use git simply we have to propose a much nicer model on
top of this assembly.
> >>
> >> Now you can systematicall save your code with monticello and
automatically publish it to git.
> >> Esteban has a script for doing that.
> >>
> >> Stef
> >>
> >>> … Pharo may be within the 30 most popular languages on Earth.
> >>> The 30th languages has 3,253 repository. There are 2,635 on
SmalltalkHub.
> >>>
> >>> I wish we had a nice Git integration.
> >>>
> >>> Alexandre
> >>
> >>
> >
> >
>

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[philippe.b...@highoctane.be]

It isn't. It is actually very easy to use git.

Time for a video :-)

Expect that for tomorrow.

Phil
Le 27 sept. 2015 12:22, "Alexandre Bergel"  a
écrit :

> I have tried several times to use Git for my project. But I do not want to
> spend time on configuring .gitattribute and other configuration file. This
> does not go in the right direction I believe. Why is it easier to use git
> with Java than it is with Pharo?
>
> Alexandre
>
>
> > On Sep 27, 2015, at 12:11 PM, Dimitris Chloupis 
> wrote:
> >
> > we have more than a nice Git integration. I have been using Github for
> my pharo project for over a year now without any issue, the last few months
> I have been using gitfiltree which is making it even easier. Definitely
> beats the alternatives .
> >
> > On Sun, Sep 27, 2015 at 12:58 PM Alexandre Bergel <
> alexandre.ber...@me.com> wrote:
> > … Pharo may be within the 30 most popular languages on Earth.
> > The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub.
> >
> > I wish we had a nice Git integration.
> >
> > Alexandre
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

Re: [Pharo-dev] TextAttributes in source code or class comment?

[philippe.b...@highoctane.be]

Le 22 sept. 2015 07:40, "Sven Van Caekenberghe"  a écrit :
>
>
> > On 21 Sep 2015, at 23:53, stepharo  wrote:
> >
> > I think that having metadata (style) language and data (source code)
mixed together is a bad idea.
> > I never like the ]lang[ tag because it is a huge hack. It does not even
exist in the Smalltalk syntax!!!
> > We save code that the parser cannot parse. What we fun idea.
> > So people are bashing for backward compatibility and we remove a bad
way to encode
> > metadata then suddenly it looks like we were doing something bad.
> >
> > Stef
>
> I am with Stef, it is a silly idea to mix the two. Nobody uses this in
Pharo. Cleaning up means simplifying too.

In the code no. But in the comments, that would be good to have back. In
color form. As we can write pillar class comments, can't we render them ?
Moose as an editor/viewer for pillar files.

Phil


>
>