Re: [Pharo-dev] Simple game framework

[Dimitris Chloupis]

Problem is that people , coders and users, tend to underestimate the
complexity of game development.

99% of the technology we use nowadays is game based.

Powerful GPUs utilized by consumer computers and supercomputer alike to
deal with highly complex problems like cancer research and simulations of
the Bing Bang.

Massive memory that is millions time large than technology that existed 30
years ago. A computer with 128GB of memory is exactly 1 million times
bigger than my first computer with 128 kbs of memory that will become 30
years old in exactly one year.

Massive super fast hard drives.

Multi core CPUs

The internet.

Anything you look around you has so massively progressed , only because of
high end games that have created the most profitable business for half a
century. No other kind of software comes remotely close to pushing the
hardware to such extremes and yet being so massively popular as high end
games.

So game APIs are extremely complex even for the simplest games. In Python
for example we have , or rather had , Pygame , it’s as massively popular
with beginners game developers as its massively unpopular with profession
or very experienced amateur game developers. The latest Pygame is basically
SDL with some extra game stuff.

Why people don’t use it beyond proof of concept ?

One word

“Simple”

What the rest of the computer world pursue as the holy grail in game
development is nothing more than a bad allergy .

Why ?

Because You will be far better in embracing the extremely complex engines
on the market even for the creation of the simplest games. The moment you
decide that using such an engine is an overkill for your so simple needs
and that you don’t have to endure their very steep learning curve is the
moment you condemn yourself to a full rewrite if there is a remote chance
of taking the game one step further.

We all know how much fun full rewrites are.

In short making games is no game.

Go use a professional engine and you can thank me later.
On Thu, 28 Dec 2017 at 19:53, Clément Bera  wrote:

> On Thu, Dec 28, 2017 at 4:39 PM, Hilaire  wrote:
>
>> What is the reason using Cairo over SDSL? Is not SDL just enought?
>
>
> My understanding is that SDL provides the surface to draw on as part of
> the window, but not a 2D vector graphic engine on top. You've got only draw
> Line/Rect/pixel functions in SDL. To render a svg/png/jpeg that you want
> for games on the SDL surface, the normal way is to use a third party
> library such as Cairo.
>
> For 3D I believe people use SDL combined with open GL or direct3D instead
> of Cairo but I don't know the details.
>
> For events (keyboard, mouse, joypad) I use SDL event management and it
> works differently on each OS. I wrote in the readMe the different set-ups
> to make it work on each OS. On Windows and Linux I can use the latest
> Pharo. On Mac I use old Pharo 5 images.
>
> I guess it's possible to use SDL for audio, but it seems there is no code
> relative to audio in the SDL binding and in OSWindow in Pharo. That's why I
> did not go that way. I tried multiple things but I successfully run audio
> code in Pharo only with the openAL binding and .wav file (and even in this
> case, I had to install external librairies in Mac OS...).
>
> Whichever if Cairo stays around or not does not really matter, normally
> one uses Cairo through Athens or Sparta, abstraction layers on top of 2D
> graphic engines. I've worked with other 2D engines and the API are always
> almost the same, so I have no doubt that if Cairo support is dropped we can
> re-bind Athens/Sparta with another 2D engine (such as engines used by web
> browsers).
>
>
>>
>> Hilaire
>>
>>
>> Le 25/12/2017 à 19:32, Clément Bera a écrit :
>>
>>>
>>> https://github.com/clementbera/wizard-battle-arena
>>>
>>> https://github.com/clementbera/SpiderInvasion
>>>
>>> Audio has always been a problem to me. I successfully run audio files
>>> with the open AL binding, but I failed to do so cross-platform. Already
>>> key-bindings coherent cross platform is difficult.
>>>
>>>
>> --
>> Dr. Geo
>> http://drgeo.eu
>>
>>
>>
>>
> --
> Clément Béra
> Pharo consortium engineer
> https://clementbera.wordpress.com/
> Bâtiment B 40, avenue Halley 59650
> Villeneuve
> d
> 
> 'Ascq
> 
>

Re: [Pharo-dev] Best wishes for 2018

[Dimitris Chloupis]

Can’t imagine myself ever coming remotely close to hating you. Big thanks
to you and the rest of the community for keeping the dream alive and
kicking. Looking back to 2011 when I first joined, Pharo has come a long
way and nowadays it looks and is comparable to other far more popular
languages and the fact our community is small is the ultimate proof of its
high productivity.

What makes me most happy with Pharo is that it has retained all the
important parts of Smalltalk and also, even though I never did and never
will hesitate for a second to compare Pharo to other languages and break
the misconceptions - prejudice against them, Pharo for me has become a
breath of fresh air, not afraid to follow its own path but at the same time
not afraid of embracing the practical needs of coders struggling with
finding bugs and retaining this direct connection with the machine instead
of being lost inside its own massive complexity.

Pharo has built a very solid yet flexible foundation that stands as the
torch that keeps the flame alive and making Smalltalk more relevant to
modern coders than ever before. It’s living proof that Smalltalk is not a
relic of the past,an outdated philosophy, great in theory , bad in practice
but a life form that is made of binary code like anything else but on the
same time far more capable of surviving, adjusting , evolving and thriving
in a world that accelerates to light speed in matters of technology and
science even though the world still struggles with basic concepts.

Like a real transformer , Pharo is technology from the future and there is
definetly more than meets the eye.

I wish health and happiness to all and as always

Keep dreaming with open mind

On Fri, 29 Dec 2017 at 11:28, Esteban Lorenzano  wrote:

> Thanks Torsten,
> I was about to write a similar mail.
>
> Thanks to everybody for allow me to be your “guy to hate” :)
> I will continue doing my best to make Pharo a better place for everybody,
> one step at a time.
>
> happy new year!
> Esteban
>
> > On 29 Dec 2017, at 09:39, Torsten Bergmann  wrote:
> >
> > Only a few days left for 2017. Thanks to all who helped shaping Pharos
> future.
> > May the lighthouse be with you in 2018 as well:
> >
> >  World backgroundImage:
> >(ZnEasy
> >getJpeg: '
> https://spotlight.it-notes.ru/wp-content/uploads/2017/08/02c48424be88ee36d5300ad89033fd82.jpg
> ')
> >   layout: #scaled
> >
> > Have fun!
> >
> > Bye
> > T.
> >
>
>
>

Re: [Pharo-dev] PharoSpur32Vm

[Nicolai Hess]

2017-07-23 23:18 GMT+02:00 Nicolai Hess :

>
>
> 2017-07-23 22:38 GMT+02:00 Nicolas Cellier  gmail.com>:
>
>>
>>
>> 2017-07-23 19:56 GMT+02:00 Nicolai Hess :
>>
>>>
>>>
>>> 2017-07-23 19:42 GMT+02:00 Hernán Morales Durand <
>>> hernan.mora...@gmail.com>:
>>>
 2017-07-22 10:03 GMT-03:00 Nicolai Hess :
 >
 > Hm, I tried to create the build environment used for the
 > windows vm build from opensmalltalk.
 >
 > I setup a cygwin environment with the same install commands as from
 > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.
 appveyor.yml
 >
 > My problems, first it is missing make and wget, I can add make and
 wget to the install command line for cygwin, but I am
 > curious why it is working on the build server ?
 >
 > Anyway, after I got this working, the build stops and building the
 pkg-config package.
 > The log says it can not find a gcc, I know that the build process
 with cygwin uses
 > i686-w64-mingw32-gcc
 > or
 > x86_64-w64-mingw32-gcc
 >
 > But I don't understand where is the missing step to tell the
 configure scripts to use the
 >
 > i686-w64-mingw32-gcc command instead of "gcc",
 >
 > again, this seems to work on the appveyor build but not locally on my
 machine.
 >
 > Any idea what I had missed?
 >

 I solved it in MinGW by adding the path of i686-w64-mingw32-gcc.exe in
 your profile. So if you profile is c:\MinGW\msys\1.0\etc\profile and
 the .exe is in /c/MinGW/msys/1.0/bin then change as administrator the
 line:

 MSYS2_PATH="/usr/local/bin:/usr/bin:/bin"

 to

 MSYS2_PATH="/c/MinGW/msys/1.0/bin:/c/MinGW/bin:/usr/local/bi
 n:/usr/bin:/bin"

 And finally

 source /etc/profile

 Cheers,

>>>
>>> I always had problems using mingw in the past. I got a working mingw
>>> environment some years ago, and a newer mingw version
>>> did not work well (some changes on the debug and exception format).
>>> But now, the build process for pharo did change. (The build instructions
>>> on github/pharo-vm are old and do not work anymore.
>>>
>>> And I hoped to get a more automatic and more reliable build process by
>>> using the same commands used by the build server for
>>> the opensmalltalk pharo vm sources.
>>>
>>> And I thought the compiler used to build the latest pharo-vm for windows
>>> is from cygwin ?
>>>
>>>
>>>
>> Hi Nicolai,
>> more exactly we cross compile from a cygwin environment for a mingw
>> target.
>> The main reason for switching to cygwin are:
>> - this is required for the 64 bit vm
>> - the other flavours on opensmallalk (squeak/newspeak) were also built
>> with cygwin, so it's more simple to maintain a single way of doing things
>>
>> Cygwin is required for the 64bits vm because of directx.
>> Indeed cygwin still provides support for the legacy directx version used
>> by the VM, while recent mingw does not.
>> Until we port to a newer API, mingw thus depends on the MS directx
>> include and library files that we redistribute for 32 bits only (and we
>> should not without permission, I plan to remove these files). That does not
>> work at all for 64 bits.
>>
>> The 64bits VM does not work either with gcc and requires clang currently.
>> installing clang in mingw is tedious, while it's a prebuilt package in
>> cygwin.
>>
>> You now know why we use cygwin, not how, maybe it does not terribly
>> helps, but it's important in order to avoid regression, or to be aware of
>> what need to be done before changing the building environment again...
>> Could you detail what you tried exactly?
>>
>
>
> Setup cygwin:
>
> CYG_MIRROR=http://cygwin.mirror.constant.com
> CYG_ROOT='c:\cygwin'
> CYG_SETUP=setup-x86.exe
> MINGW_ARCH=i686
> $CYG_SETUP -dgnqNO -R $CYG_ROOT -s "$CYG_MIRROR" -l
> "$CYG_ROOT"/var/cache/setup -P mingw64-$MINGW_ARCH-gcc-core,
> mingw64-$MINGW_ARCH-gcc-g++,mingw64-$MINGW_ARCH-headers,
> mingw64-$MINGW_ARCH-runtime,zip,mingw64-$MINGW_ARCH-clang,
> libiconv-devel,libglib2.0-devel,perl,mingw64-$MINGW_
> ARCH-zlib,cmake,mingw64-$MINGW_ARCH-win-iconv,make,wget
>
> (taken from the appveyor.xml, I needed to add make and wget, don't know
> why, from the appveyor log I see that make and wget is installed, even
> without this option...)
>
> Run the build (from an "empty" environment, that is, no other msys or
> mingw in the path environment variable)
>
> set FLAVOR=pharo.cog.spur
> set ARCH=win32x86
> set MINGW_ARCH=i686
> set CYG_ROOT=c:\cygwin
> set TRAVIS_OS_NAME=windows
> set PATH=%CYG_ROOT%\bin;p:\git\bin;%PATH%;
> git config --system  core.autocrlf input
> git clone -q --depth=5 --branch=Cog https://github.com/
> OpenSmalltalk/opensmalltalk-vm.git C:\projects\vm
> SET APPVEYOR_BUILD_FOLDER=c:\projects\vm
> git checkout -qf 88c4c56245f3308e711b38467bb7636864886d16
> %CYG_ROOT%\bin\bash -lc "cd $APPVEYOR_BUILD_FOLDER;exec 0 ./.travis_build.sh"
>
>
I still have problems building

Re: [Pharo-dev] Streaming over a UTF-8 encoded file using upToAll:

[Bernhard Pieber]

Hi Henrik,

Thanks for your answer. Sounds like a bug, then. :-/

Cheers,
Bernhard

> Am 28.12.2017 um 20:31 schrieb Henrik-Nergaard :
> 
> Hi,
> 
> #upTo: works fine.
> 
> 'test' asFileReference readStreamDo: [ :stream | stream converter:
> UTF8TextConverter new; upTo: $e ].  "'ß'"
> 
> It looks like PositionableStream>>#upToAll: assumes a 1 to 1 map per item,
> and only takes the difference between current position up to the pattern
> when found.
> 
> Best regards,
> Henrik

Re: [Pharo-dev] Flexibility of ZnUrl (For Metacello evolution)

[Dale Henrichs]

On 12/29/17 3:55 AM, Sven Van Caekenberghe wrote:



On 29 Dec 2017, at 10:35, Cyril Ferlicot D.  wrote:

Hi,

In order to improve the usage of Pharo and the git integration there is
some discussions around Metacello in order to be able to:

- Load a private git project from Metacello API
- Load a project hosted on a private server from Metacello API
- Load a project hosted on a private server with non default ssh port
from Metacello API
- Depend on a private git project in a baseline
- Depend on a project hosted on a private server in a baseline
- Depend on a project hosted on a private server with non default ssh
port in a baseline

To achieve this, Metacello needs to be able to manage urls like:

- 'g...@gitlab.ferlicot.fr:Projet/Bazard.git'
- 'ssh://g...@gitlab.ferlicot.fr:3456/Projet/Bazard.git'

and many others.

Dale wants to use Zinc to manage urls's in Pharo.

It works great for this url:

'ssh://g...@gitlab.ferlicot.fr:3456/Projet/Bazard.git' asUrl

It gives an instance of ZnUrl of the ssh scheme, gitlab.ferlicot.fr as
host, 3456 as port, git as username and #('Project' 'Bazard.git') as
segments.

Now the problem is that it does not work well for this url:

'g...@gitlab.ferlicot.fr:Projet/Bazard.git' asUrl

  ZnUrl fromString: 'g...@gitlab.ferlicot.fr/Projet/Bazard.git' defaultScheme: 
#http.

  ZnUrl fromString: 'g...@gitlab.ferlicot.fr/Projet/Bazard.git' defaultScheme: 
#ssh.

URI/URL are put in classes or types based on their scheme. If there is no 
explicit scheme in the URI/URL itself, you have to supply a default one.

That being said, the general syntax supported by ZnUrl is approximately

   scheme://username:password@host:port/segments?query#fragment

The colon right after the host is reserved for a port, a path has to start with 
a / (unless you are using relative URL's, but then you need a parent context). 
This is why I changed your example, to make it work.

There literally exist hundreds of schemes, some with very weird syntax. That is 
indeed the prerogative of a scheme, to define its own special syntax. However, 
the straightforward approach of the ZnUrl parser cannot recognise those.

The question then becomes: how to provide an extension mechanism for exotic 
schemes ?

Although the question has come up a couple of times, it has never been very 
urgent.

I know that some people have programmed around this limitation, maybe they 
could tell us what they did.


Thanks Sven.

As Cyril points out we are considering adding a new batch of urls for 
repository descriptions and the first order of business is to solve the 
parsing issue --- I would prefer NOT to bring back the old Url hiearchy 
--- which is what I would do if forced to provide a Metacello-specific 
solution ...


The overall goal is to be able have Metacello execute an expression that 
looks like the following:


  repositoryDescriptionString asUrl asMetacelloRepository

where the repositoryDescriptionString could be one of the following:

  'http://seaside.gemtalksystems.com/ss/metacello'
  'github://dalehenrich/filetree:pharo1.1/repository'
  'filetree://$GS_HOME/shared/repos/metacello/repository'

Note that the last two repository descriptions are accepted by ZnUrl, 
but require additional parsing tease out the required fields.


Cyril's examples are what is used by git as a repository description:

  'ssh://g...@gitlab.ferlicot.fr:3456/Projet/Bazard.git'
  'g...@gitlab.ferlicot.fr:Projet/Bazard.git'

Note that in these two examples from Cyril, we are missing some critical 
information: commitish and repository path need for a complete Metacello 
repository description, so I don't consider these repository 
descriptions complete.


Thierry Goubier addressed these particular issues with his GitFileTree 
repository description[1]:


  'gitfiletree://gitlab.ferlicot.fr:3456:Projet/Bazard:dev/src'

My inclination is to base the custom urls on Thierry's gitfiletree 
model, but we are still in the process of gathering requirements and 
parsing technology will be an issue once we've settled on the standard 
set of repository descriptions.


In the past Thierry has mentioned that "I would have reused ZnUrl to do 
that [iceberg using regex], but maybe they wanted to avoid ZnUrl errors 
about unknown schemes. I had to copy/paste some of the ZnUrl code into 
GitFileTree for that purpose."[2]


Looking at Thierry's implementation[1] it does look like he is able to 
pack all of the critical information into the repository description, 
but as with the github:// and filetree:// schemes additional parsing is 
required to tease out all of the fields ... I have not seen examples of 
the repository descriptions used by iceberg (yet) ...


So, Sven, it would be interesting to hear from you about any ideas that 
you might have to allow for the handling of custom url parsing within 
the ZnUrl framework... ideally we'd not have to do any scheme-specific 
post-parsing of the url and the #asMetacelloRepository method could be 
implemented

Re: [Pharo-dev] Flexibility of ZnUrl (For Metacello evolution)

[Norbert Hartl]

> Am 29.12.2017 um 10:35 schrieb Cyril Ferlicot D. :
> 
> Hi,
> 
> In order to improve the usage of Pharo and the git integration there is
> some discussions around Metacello in order to be able to:
> 
> - Load a private git project from Metacello API
> - Load a project hosted on a private server from Metacello API
> - Load a project hosted on a private server with non default ssh port
> from Metacello API
> - Depend on a private git project in a baseline
> - Depend on a project hosted on a private server in a baseline
> - Depend on a project hosted on a private server with non default ssh
> port in a baseline
> 
> To achieve this, Metacello needs to be able to manage urls like:
> 
> - 'g...@gitlab.ferlicot.fr:Projet/Bazard.git'
> - 'ssh://g...@gitlab.ferlicot.fr:3456/Projet/Bazard.git'
> 
> and many others.
> 
> Dale wants to use Zinc to manage urls's in Pharo.
> 
> It works great for this url:
> 
> 'ssh://g...@gitlab.ferlicot.fr:3456/Projet/Bazard.git' asUrl
> 
> It gives an instance of ZnUrl of the ssh scheme, gitlab.ferlicot.fr as
> host, 3456 as port, git as username and #('Project' 'Bazard.git') as
> segments.
> 
> Now the problem is that it does not work well for this url:
> 
> 'g...@gitlab.ferlicot.fr:Projet/Bazard.git' asUrl
> 
> It gives an instance of ZnUrl with #('g...@gitlab.ferlicot.fr:Projet'
> 'Bazard.git') as segments.
> 
> What do you think guys about this issue? Could the flexibility of ZnUrls
> be improved in order to be able to use it? Should Metacello use another way?
> 
Why ZnURL should be flexible to treat something that is not a URI? An URI is 
something like

:

The important part is the colon. If you split on it then the first part is 
addressing a name that can be resolved to get an entity that can digest the 
second part. That‘s it! A locator is just a special form of URI that cheats by 
saying that the second part can be used directly to locate the resource (that‘s 
the difference by identifiable resources and locatable resources meaning the 
ones that really exist)
So I cannot see how this can work. But nobody says you need to fold this into 
ZnURL. A Client is free to do something like if it starts with git I prepend 
that with ssh:// or git:// or git+ssh:// 
So the point is that if your model is the URI (it does not have to) then you 
should create valid URLs by adding missing stuff. Otherwise just have a model 
that treats URLs and your special cases. 

Norbert
> To see the full discussions:
> - Github issue: https://github.com/Metacello/metacello/issues/474
> - Metacello group discussion:
> https://groups.google.com/forum/#!topic/metacello/QbpngL6Jhg8
> 
> Have a nice day :)
> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr
> 
> http://www.synectique.eu
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
> 

Re: [Pharo-dev] Flexibility of ZnUrl (For Metacello evolution)

[Sven Van Caekenberghe]

> On 29 Dec 2017, at 10:35, Cyril Ferlicot D.  wrote:
> 
> Hi,
> 
> In order to improve the usage of Pharo and the git integration there is
> some discussions around Metacello in order to be able to:
> 
> - Load a private git project from Metacello API
> - Load a project hosted on a private server from Metacello API
> - Load a project hosted on a private server with non default ssh port
> from Metacello API
> - Depend on a private git project in a baseline
> - Depend on a project hosted on a private server in a baseline
> - Depend on a project hosted on a private server with non default ssh
> port in a baseline
> 
> To achieve this, Metacello needs to be able to manage urls like:
> 
> - 'g...@gitlab.ferlicot.fr:Projet/Bazard.git'
> - 'ssh://g...@gitlab.ferlicot.fr:3456/Projet/Bazard.git'
> 
> and many others.
> 
> Dale wants to use Zinc to manage urls's in Pharo.
> 
> It works great for this url:
> 
> 'ssh://g...@gitlab.ferlicot.fr:3456/Projet/Bazard.git' asUrl
> 
> It gives an instance of ZnUrl of the ssh scheme, gitlab.ferlicot.fr as
> host, 3456 as port, git as username and #('Project' 'Bazard.git') as
> segments.
> 
> Now the problem is that it does not work well for this url:
> 
> 'g...@gitlab.ferlicot.fr:Projet/Bazard.git' asUrl

 ZnUrl fromString: 'g...@gitlab.ferlicot.fr/Projet/Bazard.git' defaultScheme: 
#http.

 ZnUrl fromString: 'g...@gitlab.ferlicot.fr/Projet/Bazard.git' defaultScheme: 
#ssh.

URI/URL are put in classes or types based on their scheme. If there is no 
explicit scheme in the URI/URL itself, you have to supply a default one.

That being said, the general syntax supported by ZnUrl is approximately

  scheme://username:password@host:port/segments?query#fragment

The colon right after the host is reserved for a port, a path has to start with 
a / (unless you are using relative URL's, but then you need a parent context). 
This is why I changed your example, to make it work.

There literally exist hundreds of schemes, some with very weird syntax. That is 
indeed the prerogative of a scheme, to define its own special syntax. However, 
the straightforward approach of the ZnUrl parser cannot recognise those.

The question then becomes: how to provide an extension mechanism for exotic 
schemes ?

Although the question has come up a couple of times, it has never been very 
urgent.

I know that some people have programmed around this limitation, maybe they 
could tell us what they did.

> It gives an instance of ZnUrl with #('g...@gitlab.ferlicot.fr:Projet'
> 'Bazard.git') as segments.
> 
> What do you think guys about this issue? Could the flexibility of ZnUrls
> be improved in order to be able to use it? Should Metacello use another way?
> 
> To see the full discussions:
> - Github issue: https://github.com/Metacello/metacello/issues/474
> - Metacello group discussion:
> https://groups.google.com/forum/#!topic/metacello/QbpngL6Jhg8
> 
> Have a nice day :)
> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr
> 
> http://www.synectique.eu
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
> 

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] Best wishes for 2018

[Hilaire]

Don't worrry, we love you guy!

Happy new year


Le 29/12/2017 à 10:27, Esteban Lorenzano a écrit :

Thanks to everybody for allow me to be your “guy to hate”:)
I will continue doing my best to make Pharo a better place for everybody, one 
step at a time.


--
Dr. Geo
http://drgeo.eu

[Pharo-dev] Flexibility of ZnUrl (For Metacello evolution)

[Cyril Ferlicot D.]

Hi,

In order to improve the usage of Pharo and the git integration there is
some discussions around Metacello in order to be able to:

- Load a private git project from Metacello API
- Load a project hosted on a private server from Metacello API
- Load a project hosted on a private server with non default ssh port
from Metacello API
- Depend on a private git project in a baseline
- Depend on a project hosted on a private server in a baseline
- Depend on a project hosted on a private server with non default ssh
port in a baseline

To achieve this, Metacello needs to be able to manage urls like:

- 'g...@gitlab.ferlicot.fr:Projet/Bazard.git'
- 'ssh://g...@gitlab.ferlicot.fr:3456/Projet/Bazard.git'

and many others.

Dale wants to use Zinc to manage urls's in Pharo.

It works great for this url:

'ssh://g...@gitlab.ferlicot.fr:3456/Projet/Bazard.git' asUrl

It gives an instance of ZnUrl of the ssh scheme, gitlab.ferlicot.fr as
host, 3456 as port, git as username and #('Project' 'Bazard.git') as
segments.

Now the problem is that it does not work well for this url:

'g...@gitlab.ferlicot.fr:Projet/Bazard.git' asUrl

It gives an instance of ZnUrl with #('g...@gitlab.ferlicot.fr:Projet'
'Bazard.git') as segments.

What do you think guys about this issue? Could the flexibility of ZnUrls
be improved in order to be able to use it? Should Metacello use another way?

To see the full discussions:
- Github issue: https://github.com/Metacello/metacello/issues/474
- Metacello group discussion:
https://groups.google.com/forum/#!topic/metacello/QbpngL6Jhg8

Have a nice day :)

-- 
Cyril Ferlicot
https://ferlicot.fr

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



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] Best wishes for 2018

[Esteban Lorenzano]

Thanks Torsten, 
I was about to write a similar mail. 

Thanks to everybody for allow me to be your “guy to hate” :)
I will continue doing my best to make Pharo a better place for everybody, one 
step at a time.

happy new year!
Esteban

> On 29 Dec 2017, at 09:39, Torsten Bergmann  wrote:
> 
> Only a few days left for 2017. Thanks to all who helped shaping Pharos 
> future. 
> May the lighthouse be with you in 2018 as well:
> 
>  World backgroundImage: 
>(ZnEasy  
>getJpeg: 
> 'https://spotlight.it-notes.ru/wp-content/uploads/2017/08/02c48424be88ee36d5300ad89033fd82.jpg')
>   layout: #scaled
> 
> Have fun!
> 
> Bye
> T.
> 

Re: [Pharo-dev] an error in ZnResourceMetaUtils>>queryKeyValueSafeSet ?

[Esteban Lorenzano]

Hi Sven, 

A POST with this form will fail on twitter api: 

POST /1.1/statuses/update.json HTTP/1.1
Host: api.twitter.com
Content-Type: application/x-www-form-urlencoded
Accept: */*
Content-Length: 0
User-Agent: Zinc HTTP Components 1.0 (Pharo/7.0)

status=testing?

It will fail because of the “?”, if I remove ? from save and I encode as this: 

POST /1.1/statuses/update.json HTTP/1.1
Host: api.twitter.com
Content-Type: application/x-www-form-urlencoded
Accept: */*
Content-Length: 0
User-Agent: Zinc HTTP Components 1.0 (Pharo/7.0)

status=testing%3F

it will be posted correctly. 

My doubt if this is a bug in queryKeyValueSafeSet or this is a particular 
problem on twitter. If the last, I didn’t see a good way to change value of 
safe set for just one case (for now I just override the method, but this is 
clearly not good ;) ).

cheers!
Esteban 


> On 28 Dec 2017, at 13:00, Sven Van Caekenberghe  wrote:
> 
> Hi Esteban,
> 
>> On 28 Dec 2017, at 11:54, Esteban Lorenzano  wrote:
>> 
>> Hi all, Sven 
>> 
>> I’m doing some experiments with twitter and posting and I found that twitter 
>> does not accept a post with $? in the status string (it throws an error). 
>> Now, if I change ZnResourceMetaUtils>>queryKeyValueSafeSet removing $? from 
>> the safe set it works correctly. 
>> 
>> the question is: this is a twitter error or a 
>> ZnResourceMetaUtils>>queryKeyValueSafeSet error and the $? shouldn’t be 
>> considered safe (and then it should be percent encoded?)
>> 
>> cheers, 
>> Esteban
> 
> I know that the last time I did the implementation, we looked very carefully 
> in what characters are safe or not, and had some discussions about it.
> 
> I am not familiar with the API you are trying to use. I am a bit confused by 
> POST and 'status string', while encoding a query part of the URL. It is 
> possible to show exactly the call that you are trying to make ? What does an 
> equivalent curl -v call show ? Could you point to the actual API call 
> documentation ?
> 
> Sven
> 
> 

Re: [Pharo-dev] PR: Compressed sources inside the object memory

[Denis Kudriashov]

2017-12-29 10:07 GMT+01:00 Pavel Krivanek :

>
>
> 2017-12-28 22:29 GMT+01:00 Denis Kudriashov :
>
>>
>>
>> 2017-12-28 20:02 GMT+01:00 Pavel Krivanek :
>>
>>> For string searching in source codes it is 1.5s (external sources) vs
>>> 3.7s (in image compressed), for recompilation of the image it was for me
>>> 51s vs 56s.
>>>
>>
>> I expected much better performance than external file. Can it be
>> optimized?
>> I guess that every "aMethod sourceCode" decompresses full section. And it
>> can be easily cached.
>> To measure maximum speed can you check the version with uncompressed
>> inmemory sources?
>>
>
> Raw memory file has time for searching for a string in the image 2.1s BUT
> if the file is stored on disk, the time is 16.5s so about 10-times slower
> than current version. I suppose that the original fast mechanism used
> MultiByteFileStream but the new mechanism uses ZnCharacterReadStream.
>

For file sources we should use ZnBufferedReadStream over
ZnCharacterReadStream. It should lead to similar performance as old
MultiByteFileStream.


> So, in the same conditions the compressed memory stream is almost 5-times
> faster than disk access. We should try to find some optimization but I
> think that it is not necessary to do it immediately.
>
> -- Pavel
>
>
>>
>>
>>>
>>> -- Pavel
>>>
>>> 2017-12-28 17:10 GMT+01:00 Denis Kudriashov :
>>>
 2017-12-28 17:07 GMT+01:00 Denis Kudriashov :

> Interesting to compare speed of search operation like "find string in
> sources"
>

 With Calypso you can do it by:

 [(ClyMethodSources withString: 'example' from: ClyNavigationEnvironment
 currentImageScope ) execute] timeToRun



>
> 2017-12-28 16:21 GMT+01:00 Pavel Krivanek :
>
>>
>>
>> 2017-12-28 16:00 GMT+01:00 Denis Kudriashov :
>>
>>> Nice.
>>>
>>> 2017-12-28 15:50 GMT+01:00 Pavel Krivanek 
>>> :
>>>
 Hi,

 when the Pharo 7 image is being built on top of the bootstrapped
 image, all loaded code is placed in the changes file so this process 
 ends
 with an empty sources file, huge changes file and the image. We 
 condense
 the sources file for every build so we distribute the Pharo 7 as
 three files - image, huge sources (over 30 MB) and almost empty changes
 file.
 As consequence every build has own sources file that can be shared
 between images based on the same build - so when we will release the
 Pharo 7, the sources file can be shared as it was for previous
 releases, but as soon as some fixing version of Pharo 7 will be
 released, it will require a new specific sources file.

 As one possible solution I tried to create a pull request that
 resurrects from oblivion an old code made for Squeak 3.7 that 
 introduced
 option of compressed sources files. Such files use segments that are 
 stored
 in compressed form so it is not so small as one single zip file but 
 still
 good enough. From original uncompressed file of size 30.8 MB it 
 generates
 7.1 MB file while single zip has 6.1 MB.

 Of course the image file is bigger but:
 - the amount of new objects is low so it should not make much more
 stress on GC

>>>
>>> And how many objects it adds? (how many sections are compressed?)
>>>
>>
>> It uses currently 1619 segments of size 2 bytes but that does not
>> mean that such amount of objects is needed because in the memory 
>> filesystem
>> all the (compressed) data are in single ByteArray and the stream class 
>> uses
>> a very simple segments table - one big array of 1619 integer items that
>> contain indexes to the ByteArray.
>>
>>
>>>
 - we already used to have big images because the condenser was not
 working and it was not a big issue
 - the amount of distributed files will be the same as in case of
 Pharo 6 (image+changes) so it means less troubles
 - the sources file can be easily restored, deleted from the object
 memory and used the same way as before
 - we are not using the nice concept of the image well enough. All
 data that are not really shared between images or serve as backup
 information should be stored inside image

>>>
>>> Can we avoid empty changes file? We can create it on demand (when
>>> user modifies code for example).
>>>
>>
>> I think we can because it contains only do-its. We should be able to
>> simply delete it and only modify the image start-up do do not require it.
>>
>> -- Pavel
>>
>>
>>>
>>>

 Please review this PR. As a side effect it makes the sources file
 mechanism (but not changes file) independent on the FileStream
>

Re: [Pharo-dev] PR: Compressed sources inside the object memory

[Pavel Krivanek]

2017-12-28 22:29 GMT+01:00 Denis Kudriashov :

>
>
> 2017-12-28 20:02 GMT+01:00 Pavel Krivanek :
>
>> For string searching in source codes it is 1.5s (external sources) vs
>> 3.7s (in image compressed), for recompilation of the image it was for me
>> 51s vs 56s.
>>
>
> I expected much better performance than external file. Can it be optimized?
> I guess that every "aMethod sourceCode" decompresses full section. And it
> can be easily cached.
> To measure maximum speed can you check the version with uncompressed
> inmemory sources?
>

Raw memory file has time for searching for a string in the image 2.1s BUT
if the file is stored on disk, the time is 16.5s so about 10-times slower
than current version. I suppose that the original fast mechanism used
MultiByteFileStream but the new mechanism uses ZnCharacterReadStream. So,
in the same conditions the compressed memory stream is almost 5-times
faster than disk access. We should try to find some optimization but I
think that it is not necessary to do it immediately.

-- Pavel


>
>
>>
>> -- Pavel
>>
>> 2017-12-28 17:10 GMT+01:00 Denis Kudriashov :
>>
>>> 2017-12-28 17:07 GMT+01:00 Denis Kudriashov :
>>>
 Interesting to compare speed of search operation like "find string in
 sources"

>>>
>>> With Calypso you can do it by:
>>>
>>> [(ClyMethodSources withString: 'example' from: ClyNavigationEnvironment
>>> currentImageScope ) execute] timeToRun
>>>
>>>
>>>

 2017-12-28 16:21 GMT+01:00 Pavel Krivanek :

>
>
> 2017-12-28 16:00 GMT+01:00 Denis Kudriashov :
>
>> Nice.
>>
>> 2017-12-28 15:50 GMT+01:00 Pavel Krivanek :
>>
>>> Hi,
>>>
>>> when the Pharo 7 image is being built on top of the bootstrapped
>>> image, all loaded code is placed in the changes file so this process 
>>> ends
>>> with an empty sources file, huge changes file and the image. We condense
>>> the sources file for every build so we distribute the Pharo 7 as
>>> three files - image, huge sources (over 30 MB) and almost empty changes
>>> file.
>>> As consequence every build has own sources file that can be shared
>>> between images based on the same build - so when we will release the
>>> Pharo 7, the sources file can be shared as it was for previous
>>> releases, but as soon as some fixing version of Pharo 7 will be
>>> released, it will require a new specific sources file.
>>>
>>> As one possible solution I tried to create a pull request that
>>> resurrects from oblivion an old code made for Squeak 3.7 that introduced
>>> option of compressed sources files. Such files use segments that are 
>>> stored
>>> in compressed form so it is not so small as one single zip file but 
>>> still
>>> good enough. From original uncompressed file of size 30.8 MB it 
>>> generates
>>> 7.1 MB file while single zip has 6.1 MB.
>>>
>>> Of course the image file is bigger but:
>>> - the amount of new objects is low so it should not make much more
>>> stress on GC
>>>
>>
>> And how many objects it adds? (how many sections are compressed?)
>>
>
> It uses currently 1619 segments of size 2 bytes but that does not
> mean that such amount of objects is needed because in the memory 
> filesystem
> all the (compressed) data are in single ByteArray and the stream class 
> uses
> a very simple segments table - one big array of 1619 integer items that
> contain indexes to the ByteArray.
>
>
>>
>>> - we already used to have big images because the condenser was not
>>> working and it was not a big issue
>>> - the amount of distributed files will be the same as in case of
>>> Pharo 6 (image+changes) so it means less troubles
>>> - the sources file can be easily restored, deleted from the object
>>> memory and used the same way as before
>>> - we are not using the nice concept of the image well enough. All
>>> data that are not really shared between images or serve as backup
>>> information should be stored inside image
>>>
>>
>> Can we avoid empty changes file? We can create it on demand (when
>> user modifies code for example).
>>
>
> I think we can because it contains only do-its. We should be able to
> simply delete it and only modify the image start-up do do not require it.
>
> -- Pavel
>
>
>>
>>
>>>
>>> Please review this PR. As a side effect it makes the sources file
>>> mechanism (but not changes file) independent on the FileStream
>>> classes that are deprecated.
>>>
>>> PR: https://github.com/pharo-project/pharo/pull/631
>>>
>>> The pre-built image:
>>>  https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20
>>> pull%20request%20and%20branch%20Pipeline/job/PR-631/lastSucc
>>> essfulBuild/artifact/bootstrap-cache/Pharo7.0-32bit-57ddc75.zip
>>>
>>> Cheers,

[Pharo-dev] Best wishes for 2018

[Torsten Bergmann]

Only a few days left for 2017. Thanks to all who helped shaping Pharos future. 
May the lighthouse be with you in 2018 as well:

  World backgroundImage: 
(ZnEasy  
getJpeg: 
'https://spotlight.it-notes.ru/wp-content/uploads/2017/08/02c48424be88ee36d5300ad89033fd82.jpg')
layout: #scaled

Have fun!

Bye
T.