[Pharo-dev] literate programming

[Nicolai Hess]

Physically Based Rendering
an interesting book, using literate programming, as free book:
http://www.pbr-book.org/

Re: [Pharo-dev] Environment variables encoding ?

[Nicolai Hess]

2018-04-17 10:05 GMT+02:00 Sven Van Caekenberghe :

>
>
> > On 17 Apr 2018, at 09:57, Damien Pollet  wrote:
> >
> > It seems macOS normalizes UTF-8 differently from everyone else in file
> names (I think base character + composing instead of precomposed
> codepoint). That might affect PWD.
> > For environment variables, even if most sensible platforms should have
> adopted UTF-8 by now, I wouldn't be surprised if there's no official
> encoding whatsoever (i.e. they're just bytes with a 0 at the end…)
>
> ;-)
>
> We can decode everything, we have all the tools, but of course, we first
> have to know what encoding is being used. Hence my question.
>
> > On 17 April 2018 at 09:36, Sven Van Caekenberghe  wrote:
> > Hi,
> >
> > The dictionary
> >
> >  OSPlatform current environment
> >
> > contains a copy of the OS's environment variables (more correctly of the
> VM process), as key/value pairs.
> >
> > These are obtained via the following system calls:
> >
> > on macOS & *nix
> >
> >   LIBC environ
> >
> > on Windows
> >
> >   KERNEL32 GetEnvironmentStrings
>


Interestingly, this is only for the dictionary operations (asDictionary,
keysAndValuesDo...)
If you just access the variable with getEnv, it works:

OSPlatform current environment setEnv:'FOO' value:'benoît'.
OSPlatform current environment getEnv:'FOO'. "'benoît'"
OSPlatform current environment asDictionary at: 'FOO'. "'benoŒt'"



> >
> > It is however a bit unclear how these are encoded. On macOS & *nix that
> seems to be UTF8, on Windows there are some reports that it appears to be
> Latin1 - but both might be locale specific, I don't know either way.
> >
> > Does anyone know for sure ?
> >
> > I furthermore think that OSEnvironment and its subclasses, who do this
> call, should be responsible for decoding the C strings into proper Pharo
> strings, and not leave that responsibility to its users.
> >
> > Fundamentally, in the following, the decoding is still not done
> correctly and that is wrong/confusing IMHO.
> >
> > $ FOO=benoît ./pharo Pharo.image eval 'OSEnvironment current
> associations'
> > {'TERM_PROGRAM'->'Apple_Terminal'. 'TERM'->'xterm-256color'.
> 'SHELL'->'/bin/bash'. 'TMPDIR'->'/var/folders/sy/
> sndrtj9j1tq06j0lfnshmrl8gn/T/'. 'FOO'->'benoît'.
> 'Apple_PubSub_Socket_Render'->'/private/tmp/com.apple.launchd.uWk7pivcLT/Render'.
> 'TERM_PROGRAM_VERSION'->'404'. 
> 'TERM_SESSION_ID'->'845BECCD-0AB0-4686-B7F9-3A0FF84BDCB7'.
> 'USER'->'sven'. 
> 'SSH_AUTH_SOCK'->'/private/tmp/com.apple.launchd.y5oCwdUyaG/Listeners'.
> 'PATH'->'/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/texbin:/opt/X11/bin'.
> 'PWD'->'/tmp/benoît'. 'XPC_FLAGS'->'0x0'. 'XPC_SERVICE_NAME'->'0'.
> 'HOME'->'/Users/sven'. 'SHLVL'->'2'. 'LOGNAME'->'sven'.
> 'LC_CTYPE'->'UTF-8'. 'DISPLAY'->'/private/tmp/com.
> apple.launchd.lsgASYFiWW/org.macosforge.xquartz:0'.
> 'SECURITYSESSIONID'->'186a9'. 'OLDPWD'->'/tmp/benoît'.
> '_'->'/tmp/benoît/pharo-vm/Pharo.app/Contents/MacOS/Pharo'.
> '__CF_USER_TEXT_ENCODING'->'0x1F5:0x0:0x0'}
> >
> > Of course, if we change this, we will need to fix callers.
> >
> > Opinions ?
> >
> > Sven
> >
> > PS: Furthermore, I note that there is a subtle difference in how $FOO
> and $PWD in the above are UTF-8 encoded. In the former, normalisation was
> done, in the latter not. Maybe that could lead to problems (when
> comparing/composing them). This is a difficult/complex subject (
> https://medium.com/concerning-pharo/an-implementation-of-unicode-
> normalization-7c6719068f43).
> >
> >
> >
> >
> >
> >
> > --
> > Damien Pollet
> > type less, do more [ | ] http://people.untyped.org/damien.pollet
>
>
>

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

[Nicolai Hess]

How about

git config --system  core.autocrlf input

I use this in my opensmalltalk-vm git repository. (I think I saw this
option in the appveyor windows-vm build)

2018-04-10 23:44 GMT+02:00 Esteban Lorenzano :

> hi,
>
> > On 10 Apr 2018, at 23:17, Esteban A. Maringolo 
> wrote:
> >
> > Not stricly related, or maybe yes, but years ago in InfOil we started
> > using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
> > that setting to store code in the repo, we didn't have any issues
> >
> > The .gitattributes contained this:
> > *.img binary
> > *.chg binary
> > *.sml binary
> > OurImage.img merge=ours
> > OurImage.chg merge=ours
> > *.pax eol=lf
> > *.cls eol=lf
> >
> > .pax was the "package definition" and "method extensions" (methods not
> > belonging to the package) file.
> > .cls was the 1 file per class+class-side used by this scheme
> >
> > Even we did everything in Windows for some reason I don't remember (+5
> > yrs ago) LF was better for Gitlab. What I also don't remember is if
> > during the checkout in the Gitlab CI some conversion was used or not. I
> > don't remember a lot of things, but I can ask them if you want.
> >
> > But I can confirm that this "trick" does work.
> >
> > Git for Windows even asks you if you want to automatically convert CRLF
> > to LF during checkin and back to CRLF on checkout.
>
> exactly what I want, because pharo/iceberg/tonel uses the system line
> ending to write the files :)
> thanks!
>
> Esteban
>
> ps: otherwise I will need to add some support in-image and I don’t think
> is the best approach.
> pps: now it remains to see if libgit2 honours the .gitattributes config
>
> >
> > Regards,
> >
> >
> > On 10/04/2018 18:05, Esteban Lorenzano wrote:
> >> Hi,
> >>
> >> I’ve been wondering how to better fix the problem of having windows and
> >> linux/macOS people contributing and the fact that files are written in
> >> their native system format (crlf windows, lf for the rest of the world).
> >>
> >> I digged a bit and I found a couple a link that helped me (after trying
> >> to understand the
> >> doc): https://stackoverflow.com/questions/170961/whats-the-
> best-crlf-carriage-return-line-feed-handling-strategy-with-git
> >>
> >> and it seems adding a .gitattributes file with this content:
> >>
> >> # Auto detect text files and perform LF normalization
> >> *text=auto
> >> *.sttext merge=union eol=lf
> >>
> >> could fix the problem?
> >> can someone confirm this?
> >>
> >> (I confess this issue confuses me a lot :P)
> >>
> >> cheers!
> >> Esteban
> >
> > --
> > Esteban A. Maringolo
> >
>
>
>

Re: [Pharo-dev] Contribute a Fix and Reviewing changes

[Nicolai Hess]

Ah!
Ok.

2018-04-10 23:26 GMT+02:00 Peter Uhnák <i.uh...@gmail.com>:

> Hi,
>
> did you commit on Windows? Because Iceberg seems to commit in
> platform-specific line endings, so I always need to convert it manually...
> ( https://github.com/PowerShell/Win32-OpenSSH/wiki/
> Dos2Unix---Text-file-format-converters )
>

And how can I do this, if my changes are managed by iceberg ?
Do I have to manually change the files in my local branch (right at my git
directory) and can I then still upload the fix from within iceberg?


>
> Notice also that all the files are from the same directory ... when you
> commit even a single change, the entire package is filed out.
>
> Peter
>
>
>
>
> On Tue, Apr 10, 2018 at 11:16 PM, Nicolai Hess <nicolaih...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I tried to create a pull request with IceBerg.
>> I followed the CONTRIBUTING HowTo and Markus' create TechTalk-Video.
>>
>> But I must have done something wrong.
>> This is my pull request:
>> https://github.com/pharo-project/pharo/pull/1189
>> But although I just changes one line in one method.
>> The gitub pull request side shows
>> Commit 1 Files changed 40!
>> But I did not change 40 files
>>
>>
>> And I still have problems viewing pull requests from within pharo:
>>
>>
>>
>>
>>
>>
>> I thought this would work meanwhil.
>>
>>
>> Thanks in advance
>>
>> nicolai
>>
>>
>

[Pharo-dev] Contribute a Fix and Reviewing changes

[Nicolai Hess]

Hi,

I tried to create a pull request with IceBerg.
I followed the CONTRIBUTING HowTo and Markus' create TechTalk-Video.

But I must have done something wrong.
This is my pull request:
https://github.com/pharo-project/pharo/pull/1189
But although I just changes one line in one method.
The gitub pull request side shows
Commit 1 Files changed 40!
But I did not change 40 files


And I still have problems viewing pull requests from within pharo:






I thought this would work meanwhil.


Thanks in advance

nicolai

[Pharo-dev] git workflow (iceberg) and monticello packages

[Nicolai Hess]

Hi ,

I am still not sure I understand the git based development workflow.

I set up my image and repository as described by the guide.

now, if new commits are in the pharo-project, iceberg shows the list of
incoming
changes (commits). Ok, but:

If I modify code in my image (for example, change a method in class Morph),
the morphic-core package is marked as dirty in monticello and my
pharo repository in iceberg is marked with an asterisk.
If I choose "synchronize repository ..." I would expect my change to be an
uncommited change, but instead, it isn't shown and the Morphic-core package
isn't dirty anymore.

Is it because I need to create a branch first ? But why is the Morphic-core
package
not dirty anymore, the change is not commited or published, how do I know
where are my changes ?

nicolai

[Pharo-dev] Feedback about "Contribute a Fix to Pharo" (For windows users)

[Nicolai Hess]

 The setup finally somehow works:

I followed the guide at
https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo

* wget -O- get.pharo.org/70+vm | bash

Does not work (windows msys-console)
It starts donwloading something but not pharo

I tried to do at seperate steps:
Only the image
* wget -O- get.pharo.org/70 | bash

Works

* wget -O- get.pharo.org/vm | bash

works, but is the wrong VM I guess, I can not open the image

* wget -O- get.pharo.org/vm70 | bash

works, seems to load the right vm

* ./pharo-ui Pharo.image

Starts the vm but complains about :
"Pharo cannot write to the changes file named u:\tmp\pharo\Pharo.changes."

I am sure the file is writable.

The vm reports to be built on aug 27 2017, is this right?


Setting up Iceberg:
Yes, need option 2, that is, I use the commandline to clone a repository
and
add it to iceberg. Cloning from iceberg directly does not work (long file
names).

Ok,
now I see some uncommitted changes, the guide says: "you may need to invoke
synchronize"

But how?
There is a "synchronize repository... " and "Synchronize full repository
..."
menu entry.

Which one?
The first synchronize does not show me how to actually do anything
and the second one shows a intimidating warning :)
FInally I removed my fork (it was pretty old), did a new fork and sstarted
with
a fresh image.

Finally, the initial setup up is done, I now try to do some work with it
and report back


nicolai

Re: [Pharo-dev] PharoSpur32Vm

[Nicolai Hess]

2017-07-23 23:18 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:

>
>
> 2017-07-23 22:38 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com>:
>
>>
>>
>> 2017-07-23 19:56 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>>
>>>
>>>
>>> 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 <nicolaih...@gmail.com>:
>>>> >
>>>> > 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'

Re: [Pharo-dev] odd behaviour dragging method between protocols

[Nicolai Hess]

Happened to me too.
I think. I sometimes thought hey where is that method gone, couldn't
remember I deleted it.

Am 13.12.2017 03:42 schrieb "Ben Coman" :


I could just be having a brain freeze, but just sharing in case
anyone else is similarly going mad...
a few times recently in Nautilus I've dragged a method from the fourth pane
and dropped it on a protocol in the third pane and the method disappeared
from the system.  Luckily its easily recovered from Tools > Code Changes,
where it shows as deleted. But its weird that a delete could be triggered
from the action I (thought I) performed.

I've yet to detect a pattern.  Unfortunately its kind of
blink-and-you-miss-it.
Its not until a second later when selecting the target protocol
that the behaviour becomes apparent.

This is in 60527-64, Unix built on Jul 20 2017 20:40:36 Compiler: 4.6.3

cheers -ben

Re: [Pharo-dev] loading from github changes lgit classes?

[Nicolai Hess]

:) This looks interesting:

So, postload of bloc and some classes (MozEnum, SpartaCairoEnum) doing a
rebuild with this author.

2017-12-11 22:27 GMT+01:00 Esteban Lorenzano <esteba...@gmail.com>:

> honestly, this should not be happening.
> Now, I have no idea why it is happening at all ;)
>
> I mean, there is no automatic process that would have a UFFI name there
> (the only place where this can happen is on #rebuildFieldAccessors and that
> will use an UFFIGenerator author, not just UFFI.
> And also that method needs to be executed by hand…
>
> weird… can you search for UFFI in system?
>
> Esteban
>
> On 11 Dec 2017, at 22:00, Nicolai Hess <nicolaih...@gmail.com> wrote:
>
> It happens not only from lgit-classes but from other FFI-Subclasses too,
> for example AthensCairoMatrix.
>
> And some methods have a strange version history (see screenshot).
> The timestamp of all of the UFFI changes are during loading gtoolkit.
> Maybe during loading we have multiple reinitializations that will recreate
> autogenerated methods, again and again ?
>
> 2017-12-11 21:49 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:
>
>> But these aren't method changes.
>> The class definition is changed. (see screenshot)
>> It looks like it adds new class variables, even though they were alreday
>> in the original fresh image.
>>
>>
>> 2017-12-11 13:49 GMT+01:00 Max Leske <maxle...@gmail.com>:
>>
>>> Without taking a closer look, those are probably auto generated methods.
>>>
>>> Max
>>>
>>>
>>>
>>> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaih...@gmail.com)
>>> wrote:
>>>
>>> How come, loading a github project writes strange code change entries
>>> for classes
>>> like
>>> LGitFetchOptions
>>> LGitRemoteCallbacks
>>> ...
>>>
>>> For example, in a Pharo 6.1 image I load bloc like this:
>>>
>>> Metacello new
>>> baseline: 'Bloc';
>>> repository: 'github://pharo-graphics/Bloc:pharo6.1/src';
>>> load: #core
>>>
>>> In my Epicea code change window I see this entries (see screenshot).
>>> And the final "new" version of this classes, (class definitions) just
>>> look like the
>>> original class definition in a fresh image.
>>>
>>>
>>>
>>
> 
>
>
>

Re: [Pharo-dev] loading from github changes lgit classes?

[Nicolai Hess]

It happens not only from lgit-classes but from other FFI-Subclasses too,
for example AthensCairoMatrix.

And some methods have a strange version history (see screenshot).
The timestamp of all of the UFFI changes are during loading gtoolkit.
Maybe during loading we have multiple reinitializations that will recreate
autogenerated methods, again and again ?

2017-12-11 21:49 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:

> But these aren't method changes.
> The class definition is changed. (see screenshot)
> It looks like it adds new class variables, even though they were alreday
> in the original fresh image.
>
>
> 2017-12-11 13:49 GMT+01:00 Max Leske <maxle...@gmail.com>:
>
>> Without taking a closer look, those are probably auto generated methods.
>>
>> Max
>>
>>
>>
>> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaih...@gmail.com)
>> wrote:
>>
>> How come, loading a github project writes strange code change entries for
>> classes
>> like
>> LGitFetchOptions
>> LGitRemoteCallbacks
>> ...
>>
>> For example, in a Pharo 6.1 image I load bloc like this:
>>
>> Metacello new
>> baseline: 'Bloc';
>> repository: 'github://pharo-graphics/Bloc:pharo6.1/src';
>> load: #core
>>
>> In my Epicea code change window I see this entries (see screenshot).
>> And the final "new" version of this classes, (class definitions) just
>> look like the
>> original class definition in a fresh image.
>>
>>
>>
>

[Pharo-dev] create snapshots out of github based packages

[Nicolai Hess]

Is there any way to create a "snapshot" of a project from a git based
repository.
Something that creates a "condensed" old style mcz package ?
Maybe there is already something and I missed it ?

Because now I am just a little shocked how much files are created during
loading
a project.

I did some tests with gtoolkit bloc and calypso.
Sure, bloc or gtoollkit may be huge projects, but they produce thousands of
files.
And I don't mean 1 or 2 thousand files.
Loading bloc for example creates over 20.000 files.

This is damn slow on windows.

[Pharo-dev] using Pharo 7 from Pharo Launcher gives warning about changes file

[Nicolai Hess]

Just reinstalled pharo launcher new.
Select the Pharo 7 (development version) entry,
create an image and start it.

It always shows a warning about the changes :

"
Pharo cannot write to the changes file named
C:\Users\nicolai\Documents\Pharo\images\Pharo 7.0 (development
version)\Pharo 7.0 (development version).changes.

Please check that you have write permission for this file.

You won't be able to save this image correctly until you fix this."


But I can save the image, and reopening gives the same message.

I don't know if this is an Pharo 7 or a Pharo Launcher issue, but
starting a pharo 6.1 image does not give this message.

nicolai

Re: [Pharo-dev] , for vector creation

[Nicolai Hess]

Am 25.10.2017 10:50 PM schrieb "Torsten Bergmann" :

Hi,

there might be reasons for an own 2D vector class (instead of using Point).
But still I dislike the reimplementation of  "," because for me so far it
has the meaning of "concatenating things".



Like concatenating coordinates :-)



Here you redefine it to create vector instances and it works only up to
three
so far. Right?

I understand that this gives some similarities with the math notation (1,2)
but I personally would prefer to use:

1@2 asVector

or  Vector2D x: 1 y: 2

Thx
T.



> Gesendet: Mittwoch, 25. Oktober 2017 um 20:06 Uhr
> Von: "Tudor Girba" 
> An: "Pharo Development List" 
> Betreff: [Pharo-dev] , for vector creation
>
> Hi,
>
> As mentioned in the separate thread, we played with introducing the
extension:
>
> , aNumber
>   ^ BlVector2D x: self y: aNumber
>
> This means that (10,20) will return a 2D vector.
>
> We also have (10,20,30) which returns a 3D vector.
>
> , is used for different meanings already in the image beside the
collection concatenation. For example, in FileReference is adds a file
extension. And Exceptions create a collection. In other packages,
PetitParser uses it as a sequence operator.
>
> Please voice your concerns.
>
> Cheers,
> Doru
>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Every thing should have the right to be different."
>
>
>
>
>
>

Re: [Pharo-dev] Bloc Feedback

[Nicolai Hess]

2017-10-24 2:04 GMT+02:00 Sean P. DeNigris :

> Tudor Girba-2 wrote
> > Thanks for the feedback!
>
> But of course! Thanks for pushing Bloc :) IMHO a clean low-level graphics
> framework is the linchpin to unleash a tremendous amount of creativity in
> the Pharo community. I have several dream projects that I placed on
> long-term hold after getting stuck in Morphic quicksand :/
>
>
> Tudor Girba-2 wrote
> >> - How would one do e.g. a ticking clock in Bloc? The only possibly
> >> relevant
> >> example I see is BlAnimatedCursor. Is that a typical usage? One thing
> >> that
> >> I'm not sure how to translate to a BlElement is that the cursor seems to
> >> be
> >> responsible for starting and stopping the animation via #activateOn:,
> >> which
> >> doesn't exist for an element. How would one prevent an element's
> >> animation
> >> from continuing to run after a space was closed?
> > What do you mean?
>
> I guess I mean what is the Bloc version of #step that would enable us to do
> e.g. Squeak's mouse-eyes-tracking-the-cursor or Lively Kernel's clock:
> 
>
>
> Tudor Girba-2 wrote
> >> - BlElement has 278 instance-side methods. A frequent battle cry against
> >> Morphic was the bloated Morph class with 899. Definitely an improvement,
> >> but
> >> are we "there yet”?
> > What do you mean?
>
> Is there a consensus on a maximum number of instance-side methods before a
> class becomes impossible to understand, and if so where does BlElement fall
> on that scale?
>
>
>

I dont think this number alone is a problem. As long as the
"responsibility" of this
class is well structured.
A problem with the Morph class is, that it acts as many things at once.
A structured container, a model, a view, a graphical object, a widget base
...

About BlElement, I am more afraid about the number of instance variables


>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] Are assignment to block variables is prohibited?

[Nicolai Hess]

2017-09-14 21:43 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:

> Yes. But there is a setting for the compiler to load/compile code with
> errors.
>
>
> 2017-09-14 20:46 GMT+02:00 Stephane Ducasse <stepharo.s...@gmail.com>:
>
>> Hi
>>
>> I know that method arg are read only and you cannot assign to them.
>> Now what is the status of block arguments?
>> Because some old code of plotmorph is breaking.
>>
>> Stef
>>
>>

But using catalog, I can load plotmorph, even without enabling this setting.

Re: [Pharo-dev] Are assignment to block variables is prohibited?

[Nicolai Hess]

Yes. But there is a setting for the compiler to load/compile code with
errors.

2017-09-14 20:46 GMT+02:00 Stephane Ducasse :

> Hi
>
> I know that method arg are read only and you cannot assign to them.
> Now what is the status of block arguments?
> Because some old code of plotmorph is breaking.
>
> Stef
>
>

Re: [Pharo-dev] Writeup: how to contribute to Pharo

[Nicolai Hess]

2017-08-31 20:05 GMT+02:00 Stephane Ducasse <stepharo.s...@gmail.com>:

> Hi nicolai
>
> here is what I do.
> I always download the latest image via a bash script because updating can
> fail since loading package without a baseline may break.
>
> After I use the set up described by guille blog post and I reuse my
> downloaded clone (to avoid to trash my SSD).
>
> Esteban told me that he will do a video:
> - for producing a PR
> - for reviewing
>
> Stef
>

Thanks, that would be great. looking forward to it, but for now I think I
will quit trying this. It is too frustrating. I can not even try to explore
icebergs functionality because it is crashing all the time.




>
> On Thu, Aug 31, 2017 at 12:06 AM, Nicolai Hess <nicolaih...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I am now able to use iceberg on windows, thanks for the help.
>>
>> But I am still a bit unsure about how the review and contribution
>> workflow should work.
>>
>> up to pharo 6 I just load a latest image,
>> - load the slice from a fogbugz number and was able to review the change
>> - or create a slice and upload it to the inbox
>>
>> in pharo 7
>> - what is the equivalent to "getting the latest image" (and being able to
>> load and review a fix),
>>up to pharo 6 I just
>> - load the latest image in pharolauncher (or from the command line).
>> - opened the inbox repository.
>> - load and review change/fix
>> - throw away this change (close image without save)
>> - reopen that image to move on with the next item to review.
>>
>> But now, do I have to update my local branch for every new pull
>> request ? And how do I do this ? In other git project I would, I would
>> fetch upstream, checkout master, merge with upstream/master, push the
>> master to my fork origin
>>How should this be done with my pharo 7 fork ? (And do we only work on
>> the development brach instead of the master)?
>>
>>And do I this only in the command line or do I manage my fork (and
>> keep it up to date) from within pharo with iceberg ?
>>How do I actually access the pull requests from within pharo ? Maybe I
>> am stupid, but I just can not find it.
>>I would like do this steps, (as I was used to it from the prior
>> contribution process, by loading code from the inbox)
>>- Just look at the changes
>>- apply the changes
>>- throw away this changes, and move one with the next fix review
>>
>> And the same for creating a fix / pull request. Do I need to be up to
>> date with my own fork, or only the local copy of the pharo repository ?
>> Again, for pharo 6 I would just load a latest image, make my changes /
>> code fixes and create a slice. Save to the inbox -> done.
>> And looking at iceberg, I have really no clue how to upload a fix.
>>
>> I see that other people are using the new process, and I feel a bit lost
>> and closed out of the pharo 7 development process, as I am at the moment
>> unable to understand how this work.
>> Are there any other resources I missed ?
>>
>>
>>
>>
>> 2017-08-11 19:30 GMT+02:00 Stephane Ducasse <stepharo.s...@gmail.com>:
>>
>>> Nicolai
>>>
>>> I started super simple. I clone and point my fresh dled image to the use
>>> the clone.
>>> Then I can do simple PR and review the issues.
>>> I will do the installation several times to learn (but not clone).
>>>
>>> I'm not sure that it is needed but I have
>>> cd   /Users/ducasse/Library/Preferences/pharo/7.0
>>>
>>> StartupPreferencesLoader default executeAtomicItems: {
>>> StartupAction
>>> name: 'Git Settings'
>>> code: [
>>> FileStream stdout
>>> cr; nextPutAll: 'Setting the ssh
>>> credentials'; cr.
>>> Iceberg enableMetacelloIntegration: true.
>>> IceCredentialsProvider useCustomSsh: true.
>>> IceCredentialsProvider sshCredentials
>>> username: 'git';
>>> publicKey:
>>> '/Users/ducasse/.ssh/id_rsa.pub';
>>> privateKey:
>>> '/Users/ducasse/.ssh/id_rsa'.
>>>         IceCredentialsProvider
>>> plaintextCredentials:
>>> (IcePlaintextCredentials new 

Re: [Pharo-dev] review pull request changes view

[Nicolai Hess]

2017-09-01 17:44 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>:

>
> On 1 Sep 2017, at 17:18, Nicolai Hess <nicolaih...@gmail.com> wrote:
>
>
>
> 2017-09-01 17:11 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>:
>
>>
>> On 1 Sep 2017, at 17:06, Cyril Ferlicot <cyril.ferli...@gmail.com> wrote:
>>
>>
>>
>> On Fri, Sep 1, 2017 at 5:04 PM, Nicolai Hess <nicolaih...@gmail.com> w
>> rote:
>>
>>>
>>> Oh no!
>>>
>>> Now iceberg shows an empty list. Where is the pharo repository gone ?
>>> It took me a week to be at this point :(
>>>
>>> I reenabled the setting "Include system repositories by default", but
>>> still, the window is empty:
>>>
>>> 
>>>
>>>
>>> How can I get back the system repository ?
>>>
>>
>> I'm not 100% sure but I think you just need to click on "add local
>> repository", point the pharo clone and add src as subdirectory.
>>
>>
>> mmm no.
>> Better:
>>
>> IceCommitInfo allInstances anyOne repository register.
>>
>> (assuming anyOne will answer a pharo package)
>>
>
> hm, no.
>
> "IceCommitInfo allInstances" is empty.
>
>
> weird… using 6.1?
>
>
no, should I ?
I loaded the latest pharo 7 (or is it the same as 6.1?)
(get.pharo.org/70+vm)


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

Re: [Pharo-dev] review pull request changes view

[Nicolai Hess]

2017-09-01 17:11 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>:

>
> On 1 Sep 2017, at 17:06, Cyril Ferlicot <cyril.ferli...@gmail.com> wrote:
>
>
>
> On Fri, Sep 1, 2017 at 5:04 PM, Nicolai Hess <nicolaih...@gmail.com>
> wrote:
>
>>
>> Oh no!
>>
>> Now iceberg shows an empty list. Where is the pharo repository gone ?
>> It took me a week to be at this point :(
>>
>> I reenabled the setting "Include system repositories by default", but
>> still, the window is empty:
>>
>> 
>>
>>
>> How can I get back the system repository ?
>>
>
> I'm not 100% sure but I think you just need to click on "add local
> repository", point the pharo clone and add src as subdirectory.
>
>
> mmm no.
> Better:
>
> IceCommitInfo allInstances anyOne repository register.
>
> (assuming anyOne will answer a pharo package)
>

hm, no.

"IceCommitInfo allInstances" is empty.



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

Re: [Pharo-dev] review pull request changes view

[Nicolai Hess]

2017-09-01 17:09 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:

>
>
> 2017-09-01 17:06 GMT+02:00 Cyril Ferlicot <cyril.ferli...@gmail.com>:
>
>>
>>
>> On Fri, Sep 1, 2017 at 5:04 PM, Nicolai Hess <nicolaih...@gmail.com>
>> wrote:
>>
>>>
>>> Oh no!
>>>
>>> Now iceberg shows an empty list. Where is the pharo repository gone ?
>>> It took me a week to be at this point :(
>>>
>>> I reenabled the setting "Include system repositories by default", but
>>> still, the window is empty:
>>>
>>> [image: Inline-Bild 1]
>>>
>>>
>>> How can I get back the system repository ?
>>>
>>
>> I'm not 100% sure but I think you just need to click on "add local
>> repository", point the pharo clone and add src as subdirectory.
>>
>
> yes, seems to work.
>
>

But, is the

GitHub -> Review pull requests 

menu entry gone? I can not find it anymore.


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

Re: [Pharo-dev] review pull request changes view

[Nicolai Hess]

2017-09-01 17:06 GMT+02:00 Cyril Ferlicot <cyril.ferli...@gmail.com>:

>
>
> On Fri, Sep 1, 2017 at 5:04 PM, Nicolai Hess <nicolaih...@gmail.com>
> wrote:
>
>>
>> Oh no!
>>
>> Now iceberg shows an empty list. Where is the pharo repository gone ?
>> It took me a week to be at this point :(
>>
>> I reenabled the setting "Include system repositories by default", but
>> still, the window is empty:
>>
>> [image: Inline-Bild 1]
>>
>>
>> How can I get back the system repository ?
>>
>
> I'm not 100% sure but I think you just need to click on "add local
> repository", point the pharo clone and add src as subdirectory.
>

yes, seems to work.


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

Re: [Pharo-dev] review pull request changes view

[Nicolai Hess]

2017-09-01 16:48 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:

>
>
> 2017-09-01 16:29 GMT+02:00 Cyril Ferlicot <cyril.ferli...@gmail.com>:
>
>> On Fri, Sep 1, 2017 at 4:26 PM, Nicolai Hess <nicolaih...@gmail.com>
>> wrote:
>> >
>> >
>> >
>> > update what? pharo ?
>> >
>> >
>>
>> You can update Iceberg by executing:
>>
>> #('Iceberg-UI' 'Iceberg-Plugin' 'Iceberg-Metacello-Integration'
>> 'Iceberg-Libgit' 'Iceberg' 'BaselineOfIceberg' 'LibGit-Core'
>> 'BaselineOfLibGit')
>> do: [ :each | each asPackage removeFromSystem ].
>>
>> Metacello new
>>   baseline: 'Iceberg';
>>   repository: 'github://pharo-vcs/iceberg:dev-0.5';
>>   load.
>>
>>
>>
> Ah, thanks. I will try it out and report back if the crashes still occur.
>
>

Oh no!

Now iceberg shows an empty list. Where is the pharo repository gone ?
It took me a week to be at this point :(

I reenabled the setting "Include system repositories by default", but
still, the window is empty:

[image: Inline-Bild 1]


How can I get back the system repository ?


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

Re: [Pharo-dev] review pull request changes view

[Nicolai Hess]

2017-09-01 16:29 GMT+02:00 Cyril Ferlicot <cyril.ferli...@gmail.com>:

> On Fri, Sep 1, 2017 at 4:26 PM, Nicolai Hess <nicolaih...@gmail.com>
> wrote:
> >
> >
> >
> > update what? pharo ?
> >
> >
>
> You can update Iceberg by executing:
>
> #('Iceberg-UI' 'Iceberg-Plugin' 'Iceberg-Metacello-Integration'
> 'Iceberg-Libgit' 'Iceberg' 'BaselineOfIceberg' 'LibGit-Core'
> 'BaselineOfLibGit')
> do: [ :each | each asPackage removeFromSystem ].
>
> Metacello new
>   baseline: 'Iceberg';
>   repository: 'github://pharo-vcs/iceberg:dev-0.5';
>   load.
>
>
>
Ah, thanks. I will try it out and report back if the crashes still occur.


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

Re: [Pharo-dev] review pull request changes view

[Nicolai Hess]

2017-09-01 14:48 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:

> When reviewing a pull request, I see this in the changes view:
> The tab title says
> "left working copy / right incoming update"
> but the code on the right side is what is current in my image
>
> [image: Inline-Bild 1]
>
>
> And I don't think "working copy" is the correct naming, as this view lets
> me diff changes within
> that history, so it may be that none of this code is actually in my
> "working copy", no ?
>

And how do I know if a pull request / change is already included ?

I looked at a pull request
and it seems this change is already in my image (a fresh image from 30.08
(Pharo7.0alpha.build.78.sha.35c21c3fac9b557eb38ec569fbbb109f2015c71a)
The pull request (https://api.github.com/repos/pharo-project/pharo/pulls/231)
is  "open", but I can see the new code already in my image.

The diff view tells me, that the method
UITheme>>warningTextColor changes from

warningTextColor
^ Color yellow muchDarker

to

warningTextColor
^ Color yellow

But the method in the image already looks like this:

warningTextColor
^ Color yellow

Re: [Pharo-dev] review pull request changes view

[Nicolai Hess]

2017-09-01 16:13 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>:

>
> On 1 Sep 2017, at 16:02, Esteban Lorenzano <esteba...@gmail.com> wrote:
>
>
> On 1 Sep 2017, at 15:50, Nicolai Hess <nicolaih...@gmail.com> wrote:
>
>
>
> 2017-09-01 15:03 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>:
>
>>
>> On 1 Sep 2017, at 14:51, Nicolai Hess <nicolaih...@gmail.com> wrote:
>>
>>
>>
>> 2017-09-01 14:48 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>>
>>> When reviewing a pull request, I see this in the changes view:
>>> The tab title says
>>> "left working copy / right incoming update"
>>> but the code on the right side is what is current in my image
>>>
>>> 
>>>
>>>
>>> And I don't think "working copy" is the correct naming, as this view
>>> lets me diff changes within
>>> that history, so it may be that none of this code is actually in my
>>> "working copy", no ?
>>>
>>
>>
>> BTW, this is extremly unstable, reviewing a pull request, crashes a lot
>> (the vm)
>>
>>
>> on windows?
>>
>>
>>
>>
> Yes,
>
> attached a another crash.dmp (maybe it helps)
>
> 
>
>
> can you tell me the PR you were analysing ?
>
>
> ah, and btw… can you update with latest dev-0.5? I made some changes that
> may help there that I still do not merge into master.
>

update what? pharo ?


>
> Esteban
>
>
> Esteban
>
>
>

Re: [Pharo-dev] review pull request changes view

[Nicolai Hess]

2017-09-01 16:02 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>:

>
> On 1 Sep 2017, at 15:50, Nicolai Hess <nicolaih...@gmail.com> wrote:
>
>
>
> 2017-09-01 15:03 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>:
>
>>
>> On 1 Sep 2017, at 14:51, Nicolai Hess <nicolaih...@gmail.com> wrote:
>>
>>
>>
>> 2017-09-01 14:48 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>>
>>> When reviewing a pull request, I see this in the changes view:
>>> The tab title says
>>> "left working copy / right incoming update"
>>> but the code on the right side is what is current in my image
>>>
>>> 
>>>
>>>
>>> And I don't think "working copy" is the correct naming, as this view
>>> lets me diff changes within
>>> that history, so it may be that none of this code is actually in my
>>> "working copy", no ?
>>>
>>
>>
>> BTW, this is extremly unstable, reviewing a pull request, crashes a lot
>> (the vm)
>>
>>
>> on windows?
>>
>>
>>
>>
> Yes,
>
> attached a another crash.dmp (maybe it helps)
>
> 
>
>
> can you tell me the PR you were analysing ?
>

https://api.github.com/repos/pharo-project/pharo/pulls/237


>
> Esteban
>

Re: [Pharo-dev] review pull request changes view

[Nicolai Hess]

2017-09-01 15:03 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>:

>
> On 1 Sep 2017, at 14:51, Nicolai Hess <nicolaih...@gmail.com> wrote:
>
>
>
> 2017-09-01 14:48 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>
>> When reviewing a pull request, I see this in the changes view:
>> The tab title says
>> "left working copy / right incoming update"
>> but the code on the right side is what is current in my image
>>
>> 
>>
>>
>> And I don't think "working copy" is the correct naming, as this view lets
>> me diff changes within
>> that history, so it may be that none of this code is actually in my
>> "working copy", no ?
>>
>
>
> BTW, this is extremly unstable, reviewing a pull request, crashes a lot
> (the vm)
>
>
> on windows?
>
>
>
>
Yes,

attached a another crash.dmp (maybe it helps)


crash.dmp
Description: Binary data

Re: [Pharo-dev] review pull request changes view

[Nicolai Hess]

2017-09-01 14:48 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:

> When reviewing a pull request, I see this in the changes view:
> The tab title says
> "left working copy / right incoming update"
> but the code on the right side is what is current in my image
>
> [image: Inline-Bild 1]
>
>
> And I don't think "working copy" is the correct naming, as this view lets
> me diff changes within
> that history, so it may be that none of this code is actually in my
> "working copy", no ?
>


BTW, this is extremly unstable, reviewing a pull request, crashes a lot
(the vm)

[Pharo-dev] review pull request changes view

[Nicolai Hess]

When reviewing a pull request, I see this in the changes view:
The tab title says
"left working copy / right incoming update"
but the code on the right side is what is current in my image

[image: Inline-Bild 1]


And I don't think "working copy" is the correct naming, as this view lets
me diff changes within
that history, so it may be that none of this code is actually in my
"working copy", no ?

[Pharo-dev] reviewing pull request are adding new remotes

[Nicolai Hess]

Is it right, that reviewing a pull request will add the others user git
repository in my
list of remotes ?
This may make sense if I actually merge the pull into my branch. But if I
just want
to see the code, or merge it into the image, do I need that repository in
my list of
remotes ?

Re: [Pharo-dev] Writeup: how to contribute to Pharo

[Nicolai Hess]

2017-08-31 0:28 GMT+02:00 Cyril Ferlicot D. <cyril.ferli...@gmail.com>:

> Le 31/08/2017 à 00:06, Nicolai Hess a écrit :
> > Hi,
> >
> > I am now able to use iceberg on windows, thanks for the help.
> >
> > But I am still a bit unsure about how the review and contribution
> > workflow should work.
> >
> > up to pharo 6 I just load a latest image,
> > - load the slice from a fogbugz number and was able to review the change
> > - or create a slice and upload it to the inbox
> >
> > in pharo 7
> > - what is the equivalent to "getting the latest image" (and being able
> > to load and review a fix),
> >up to pharo 6 I just
> > - load the latest image in pharolauncher (or from the command line).
> > - opened the inbox repository.
> > - load and review change/fix
> > - throw away this change (close image without save)
> > - reopen that image to move on with the next item to review.
> >
>
> Hi,
>
> I'll not be of a great help here since I only reviewed PR via the github
> interface for now but I know that Guille wrote this guide:
> https://github.com/guillep/PharoIntegrationProcess/wiki/
> Pharo-Development-Process
>
> There is a review process discription.
>

Thank you Cyril.

Do we have a list of links to this and other usefull articles or how did
you know about this article?

Re: [Pharo-dev] Writeup: how to contribute to Pharo

[Nicolai Hess]

Hi,

I am now able to use iceberg on windows, thanks for the help.

But I am still a bit unsure about how the review and contribution workflow
should work.

up to pharo 6 I just load a latest image,
- load the slice from a fogbugz number and was able to review the change
- or create a slice and upload it to the inbox

in pharo 7
- what is the equivalent to "getting the latest image" (and being able to
load and review a fix),
   up to pharo 6 I just
- load the latest image in pharolauncher (or from the command line).
- opened the inbox repository.
- load and review change/fix
- throw away this change (close image without save)
- reopen that image to move on with the next item to review.

But now, do I have to update my local branch for every new pull request
? And how do I do this ? In other git project I would, I would
fetch upstream, checkout master, merge with upstream/master, push the
master to my fork origin
   How should this be done with my pharo 7 fork ? (And do we only work on
the development brach instead of the master)?

   And do I this only in the command line or do I manage my fork (and keep
it up to date) from within pharo with iceberg ?
   How do I actually access the pull requests from within pharo ? Maybe I
am stupid, but I just can not find it.
   I would like do this steps, (as I was used to it from the prior
contribution process, by loading code from the inbox)
   - Just look at the changes
   - apply the changes
   - throw away this changes, and move one with the next fix review

And the same for creating a fix / pull request. Do I need to be up to date
with my own fork, or only the local copy of the pharo repository ?
Again, for pharo 6 I would just load a latest image, make my changes / code
fixes and create a slice. Save to the inbox -> done.
And looking at iceberg, I have really no clue how to upload a fix.

I see that other people are using the new process, and I feel a bit lost
and closed out of the pharo 7 development process, as I am at the moment
unable to understand how this work.
Are there any other resources I missed ?



2017-08-11 19:30 GMT+02:00 Stephane Ducasse <stepharo.s...@gmail.com>:

> Nicolai
>
> I started super simple. I clone and point my fresh dled image to the use
> the clone.
> Then I can do simple PR and review the issues.
> I will do the installation several times to learn (but not clone).
>
> I'm not sure that it is needed but I have
> cd   /Users/ducasse/Library/Preferences/pharo/7.0
>
> StartupPreferencesLoader default executeAtomicItems: {
> StartupAction
> name: 'Git Settings'
> code: [
> FileStream stdout
> cr; nextPutAll: 'Setting the ssh
> credentials'; cr.
> Iceberg enableMetacelloIntegration: true.
> IceCredentialsProvider useCustomSsh: true.
> IceCredentialsProvider sshCredentials
> username: 'git';
> publicKey:
> '/Users/ducasse/.ssh/id_rsa.pub';
> privateKey:
> '/Users/ducasse/.ssh/id_rsa'.
> IceCredentialsProvider
> plaintextCredentials:
> (IcePlaintextCredentials new username: 'Ducasse'; password: '' ;
> yourself ).
> FileStream stdout
> cr; nextPutAll: 'Finished'; cr ].
> }.
>
>
>
> On Fri, Aug 11, 2017 at 9:46 AM, Guillermo Polito <
> guillermopol...@gmail.com> wrote:
>
>> I extended the document with some windows specific instructions also.
>>
>> On Fri, Aug 11, 2017 at 9:31 AM, Guillermo Polito <
>> guillermopol...@gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, Aug 11, 2017 at 12:34 AM, Nicolai Hess <nicolaih...@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> 2017-08-10 17:17 GMT+02:00 Guillermo Polito <guillermopol...@gmail.com>
>>>> :
>>>>
>>>>> Hi,
>>>>>
>>>>> I've made some write up for the pharo part (not metacello or external
>>>>> projects)
>>>>>
>>>>> https://github.com/guillep/PharoIntegrationProcess/wiki/Cont
>>>>> ribute-a-fix-to-Pharo
>>>>>
>>>>> Of course, expect bugs on it :) Not everything is smooth. If you have
>>>>> comments, they are welcome.
>>>>>
>>>>
>>>>
>>>>
>>>> [image: Inline-Bild 1]
>>>>
>>>>
>>>> In option 2, I think this should be "Click on the Edit button&q

Re: [Pharo-dev] Writeup: how to contribute to Pharo

[Nicolai Hess]

2017-08-10 17:17 GMT+02:00 Guillermo Polito :

> Hi,
>
> I've made some write up for the pharo part (not metacello or external
> projects)
>
> https://github.com/guillep/PharoIntegrationProcess/wiki/Cont
> ribute-a-fix-to-Pharo
>
> Of course, expect bugs on it :) Not everything is smooth. If you have
> comments, they are welcome.
>
> Guille
>

Maybe I mixed something up, but following the other (pavel)howto  I thought
that I would
clone the origin repository, (and edit iceberg to use the local clone as
the origin)
and later define my (github)-fork as another remote.

But in your screenshots, it looks like you cloned your pharo fork, and set
the original pharo git project as another remote.
Are both options equal and just differe in which remote is called "pharo"
and which is called "origin" ?


>
> --
>
>
>
> Guille Polito
>
>
> Research Engineer
>
> French National Center for Scientific Research - *http://www.cnrs.fr*
> 
>
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>

Re: [Pharo-dev] Writeup: how to contribute to Pharo

[Nicolai Hess]

2017-08-10 17:17 GMT+02:00 Guillermo Polito :

> Hi,
>
> I've made some write up for the pharo part (not metacello or external
> projects)
>
> https://github.com/guillep/PharoIntegrationProcess/wiki/Cont
> ribute-a-fix-to-Pharo
>
> Of course, expect bugs on it :) Not everything is smooth. If you have
> comments, they are welcome.
>



[image: Inline-Bild 1]


In option 2, I think this should be "Click on the Edit button",




>
> Guille
>
> --
>
>
>
> Guille Polito
>
>
> Research Engineer
>
> French National Center for Scientific Research - *http://www.cnrs.fr*
> 
>
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>

Re: [Pharo-dev] Writeup: how to contribute to Pharo

[Nicolai Hess]

Am 11.08.2017 12:02 vorm. schrieb "Cyril Ferlicot D." <
cyril.ferli...@gmail.com>:

Le 10/08/2017 à 23:58, Nicolai Hess a écrit :
>
> What does "clone using sourcetree" mean?
>
>

IIRC SourceTree is a Git GUI available on Windows, as GitKraken,
SmartGit, GitExtensions, TortoiseGit…


Ok, so I can just clone via command line
git clone 




--
Cyril Ferlicot
https://ferlicot.fr

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

Re: [Pharo-dev] Writeup: how to contribute to Pharo

[Nicolai Hess]

Am 10.08.2017 11:21 nachm. schrieb "Guillermo Polito" <
guillermopol...@gmail.com>:



On Thu, Aug 10, 2017 at 9:39 PM, Torsten Bergmann  wrote:

> Hi Guille,
>
> nice writeup and definitely needed. Thanks a lot!
>
> If possible you should complete it with:
>  - how Windows users could contribute
>

Hard topic. I'm taking benefit of my gf's windows computer right now to
test. Basically, windows has problems with long paths but there are
workarounds. Icerberg works by default without any changes (same bugs as in
linux and osx at least :)). Here are my notes to make it work:

* Download latest pharo:
  - http://files.pharo.org/image/70/latest-32.zip
  - http://files.pharo.org/vm/pharo-spur32/win/stable-20170720.zip

* Clone using sourcetree
   This is very slow and failed to checkout (not clone) because of the
"Filename too long errors"


What does "clone using sourcetree" mean?



I found for this the following workaround: http://pingec.si/blog/
articles/msysgit-longpath/

Once I did that, sourcetree worked nicely, and I could commit and change
branches using iceberg.

Warning: I did not test making changes on the "long files" to see what
happens...


>  -  that #development branch is used instead of master
>

I'll make another writeup about the entire process.


>   - how one can keep his own fork up to date
>

And about this one too


>
> Also it would be good to have the AboutBox in Pharo with the build number
>  again.
>

> Because the ZeroCnnf just gives you a Pharo.image and nobody knows what
> the build number
> or sha was to reproduce how old or new this is.
>

Well, actually right now

SystemVersion current

has the hash of the commit the image was generated from if you check the
inspector. It's then a UI problem and easy to fix. Maybe somebody could use
this to try making a pull request?

Then, we could add a build number in SystemVersion of course.

Guille

>
> Thanks
> T.
>
>
> *Gesendet:* Donnerstag, 10. August 2017 um 17:17 Uhr
> *Von:* "Guillermo Polito" 
> *An:* "Discusses Development of Pharo" 
> *Betreff:* [Pharo-dev] Writeup: how to contribute to Pharo
> Hi,
>
> I've made some write up for the pharo part (not metacello or external
> projects)
>
> https://github.com/guillep/PharoIntegrationProcess/wiki/Cont
> ribute-a-fix-to-Pharo
>
> Of course, expect bugs on it :) Not everything is smooth. If you have
> comments, they are welcome.
>
> Guille
>
> --
>
>
>
> Guille Polito
>
>
>
> Research Engineer
>
> French National Center for Scientific Research - *http://www.cnrs.fr*
> 
>
>
>
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>



-- 



Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*




*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>

Re: [Pharo-dev] Pharo 7 provisional HOWTO

[Nicolai Hess]

2017-08-09 9:33 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>:

>
> On 8 Aug 2017, at 23:47, Cyril Ferlicot D. <cyril.ferli...@gmail.com>
> wrote:
>
> Le 08/08/2017 à 23:40, Nicolai Hess a écrit :
>
> Thanks for the info, cyril.
>
> What do you use for the ssh username in pharo setting and what username
> did you use for creating the ssh-key ?
> I tried both, my github-email and my github-username, I didn't get it to
> work.
>
>
> I did not use anything special. While creating the ssh key I used all
> the default options and in the setting I do not change the username (see
> joined screenshot).
>
> This is the command I probably used since I followed github tutorial[1]:
>
> ssh-keygen -t rsa -b 4096 -C "cyril.ferli...@gmail.com"
>
> [1] https://help.github.com/articles/connecting-to-github-with-ssh/
>
>
> yes, the keys may be an issue, but the standard rsa generated key should
> work. We need to do a pass in security/credentials system (and probably a
> revamp of some parts), but I still didn’t find the time.
> about the 255 limitation, if you execute this in command line:
>
> git config --system core.longpaths true
>
> it should also fix the problem with pharo repo.
>
> Esteban
>

Now I have the same problem. I can not get the pharo repo because it can
not operate on files with long path names.
even with longpaths true, this does not work ...


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

Re: [Pharo-dev] Pharo 7 provisional HOWTO

[Nicolai Hess]

2017-08-09 23:18 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:

>
>
> 2017-08-08 23:41 GMT+02:00 Cyril Ferlicot D. <cyril.ferli...@gmail.com>:
>
>> Le 08/08/2017 à 23:37, Nicolai Hess a écrit :
>> >
>> >
>> > Like I described above.
>> >
>> > I followed this howto ( the first mail from pavel).
>> >
>> > But I get this error:
>> >
>> > 'LGit_GIT_ERROR: Failed to authenticate SSH session: Callback returned
>> > error'
>> >
>> >
>> > Now I enabled the setting for "Use custom SSH keys", followed the
>> > github-doc for adding a ssh-key on windows and add this key to my
>> > github-account.
>> > But I still get the same error.
>> >
>> >
>>
>> To be sure this is not a ssh key problem you can try to install git bash
>> and to commit on a repository with a ssh remote. If it works you'll be
>> sure the ssh key is good.
>>
>>
> yes, just tested, this seems to work. I can use the key for a ssh remote
> commit from the command line.
> but somehow I can not use it with pharo /iceberg..
>
>

Ah, I think I got it to work now.
I created a new ssh key, but this time I did not set a passphrase.
So maybe, ssh remotes with iceberg are only working if you don't use
passphrases for you secret key!


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

Re: [Pharo-dev] Pharo 7 provisional HOWTO

[Nicolai Hess]

2017-08-08 23:41 GMT+02:00 Cyril Ferlicot D. <cyril.ferli...@gmail.com>:

> Le 08/08/2017 à 23:37, Nicolai Hess a écrit :
> >
> >
> > Like I described above.
> >
> > I followed this howto ( the first mail from pavel).
> >
> > But I get this error:
> >
> > 'LGit_GIT_ERROR: Failed to authenticate SSH session: Callback returned
> > error'
> >
> >
> > Now I enabled the setting for "Use custom SSH keys", followed the
> > github-doc for adding a ssh-key on windows and add this key to my
> > github-account.
> > But I still get the same error.
> >
> >
>
> To be sure this is not a ssh key problem you can try to install git bash
> and to commit on a repository with a ssh remote. If it works you'll be
> sure the ssh key is good.
>
>
yes, just tested, this seems to work. I can use the key for a ssh remote
commit from the command line.
but somehow I can not use it with pharo /iceberg..


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

Re: [Pharo-dev] Shouldn't new:0 fail for non-indexable classes

[Nicolai Hess]

2017-08-09 22:14 GMT+02:00 Eliot Miranda <eliot.mira...@gmail.com>:

> Hi Nicolai,
>
> On Tue, Aug 8, 2017 at 12:10 PM, Nicolai Hess <nicolaih...@gmail.com>
> wrote:
>
>> see fogbugz 20246 (https://pharo.fogbugz.com/f/c
>> ases/20246/Segfault-calling-new-0)
>>
>> Create a class with a single instance variable.
>>
>> call
>>
>> AClass new:0
>>
>> -> segfaults (on windows latest vm).
>> I can reproduce this on squeak (Squeak5.1-16549-32bit). It does not crash
>> right away, but
>> I was able to crash it by debugging into the new: call.
>>
>> from the comment of Behavior>>#new: , I would expect the error:
>>
>> self error: self printString, ' cannot have variable sized instances'
>>
>
> Quite right.  Squeak and Pharo used to have a funky class DirectoryEntry
> that was expected to be able to be instantiated with DirectoryEntry new:
> 0.  The (Spur) VM bug is that the object was being filled with 0's instead
> of nil.  I've fixed the Spur VM to now fail for any non-indexable class
> since, AFAICT, DirectoryEntry is no longer used in this way.
>

Thank you!


>
> _,,,^..^,,,_
> best, Eliot
>

Re: [Pharo-dev] Pharo 7 provisional HOWTO

[Nicolai Hess]

2017-08-08 23:05 GMT+02:00 Cyril Ferlicot D. <cyril.ferli...@gmail.com>:

> Le 08/08/2017 à 20:40, Nicolai Hess a écrit :
> >
> > Any news on howto use iceberg / libgit on windows.
> > Does no one else use windows ?
> >
>
> Hi,
>
> I can use Iceberg on Windows 7 but not to participate to Pharo (or any
> project with file name longer than 255chars).
>
> So I can work on my projects or on projects like Iceberg. I have a ssh
> key on my Windows that is associated to my github account and I have a
> startup script executing this:
>
> IceCredentialsProvider useCustomSsh: true.
>
> Since my ssh key has the default name for a rsa key it select it by
> default and I can use Iceberg.
>

Thanks for the info, cyril.

What do you use for the ssh username in pharo setting and what username did
you use for creating the ssh-key ?
I tried both, my github-email and my github-username, I didn't get it to
work.


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

Re: [Pharo-dev] Pharo 7 provisional HOWTO

[Nicolai Hess]

2017-08-08 23:00 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>:

>
>
> On 8 Aug 2017, at 20:40, Nicolai Hess <nicolaih...@gmail.com> wrote:
>
>
>
> 2017-07-28 23:19 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>
>>
>>
>> 2017-07-28 23:13 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>>
>>>
>>>
>>> 2017-07-24 9:45 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>>>
>>>>
>>>>
>>>> 2017-07-11 12:46 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>>>>
>>>>>
>>>>>
>>>>> 2017-07-11 12:44 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>>>>>
>>>>>>
>>>>>>
>>>>>> 2017-07-11 12:28 GMT+02:00 Pavel Krivanek <pavel.kriva...@gmail.com>:
>>>>>>
>>>>>>> What is the system you use?
>>>>>>> AFAIK Esteban is fixing the latest Iceberg because it stopped to
>>>>>>> work on Windows...
>>>>>>>
>>>>>>> -- Pavel
>>>>>>>
>>>>>>
>>>>>> windows 10 32 bit
>>>>>>
>>>>>
>>>>> and on another windows 10 64  bit system
>>>>>
>>>>> on both, it crashes on working with libgit/iceberg
>>>>>
>>>>
>>>>
>>>> Any news ?
>>>> Anyone got a working libgit/iceberg for windows 32 or windows 64 ?
>>>>
>>>> Or is there any other way to be up to date with fixes, doing reviews
>>>> and bug fixes (without using github in the web browser) ?
>>>>
>>>
>>> Now, I tried again with the latest vm/image version and I get this error
>>>
>>> LGit_GIT_ERROR: username does not match previous request'
>>>
>>> Any idea ?
>>>
>>>
>>
>> I used my git username in the ssh settings.
>> If I use "git" as username for the ssh setting, it complains about
>> failed to authenticate SSH session
>>
>> How do other windows users use all this for pharo 7, any windows user how
>> can write a little howto ?
>>
>>
>
> Any news on howto use iceberg / libgit on windows.
> Does no one else use windows ?
>
>
> I do not understand what's the problem. It was working on my tests... and
> I know several people is using windows (Torsten one of them).
> What's the problem you are having in concrete? I need to see how to
> reproduce it :(
>

Like I described above.

I followed this howto ( the first mail from pavel).

But I get this error:

'LGit_GIT_ERROR: Failed to authenticate SSH session: Callback returned
error'


Now I enabled the setting for "Use custom SSH keys", followed the
github-doc for adding a ssh-key on windows and add this key to my
github-account.
But I still get the same error.



>
> Esteban
>
>
>

[Pharo-dev] Shouldn't new:0 fail for non-indexable classes

[Nicolai Hess]

see fogbugz 20246 (
https://pharo.fogbugz.com/f/cases/20246/Segfault-calling-new-0)

Create a class with a single instance variable.

call

AClass new:0

-> segfaults (on windows latest vm).
I can reproduce this on squeak (Squeak5.1-16549-32bit). It does not crash
right away, but
I was able to crash it by debugging into the new: call.

from the comment of Behavior>>#new: , I would expect the error:

self error: self printString, ' cannot have variable sized instances'

Re: [Pharo-dev] Pharo 7 provisional HOWTO

[Nicolai Hess]

2017-07-28 23:19 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:

>
>
> 2017-07-28 23:13 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>
>>
>>
>> 2017-07-24 9:45 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>>
>>>
>>>
>>> 2017-07-11 12:46 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>>>
>>>>
>>>>
>>>> 2017-07-11 12:44 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>>>>
>>>>>
>>>>>
>>>>> 2017-07-11 12:28 GMT+02:00 Pavel Krivanek <pavel.kriva...@gmail.com>:
>>>>>
>>>>>> What is the system you use?
>>>>>> AFAIK Esteban is fixing the latest Iceberg because it stopped to work
>>>>>> on Windows...
>>>>>>
>>>>>> -- Pavel
>>>>>>
>>>>>
>>>>> windows 10 32 bit
>>>>>
>>>>
>>>> and on another windows 10 64  bit system
>>>>
>>>> on both, it crashes on working with libgit/iceberg
>>>>
>>>
>>>
>>> Any news ?
>>> Anyone got a working libgit/iceberg for windows 32 or windows 64 ?
>>>
>>> Or is there any other way to be up to date with fixes, doing reviews and
>>> bug fixes (without using github in the web browser) ?
>>>
>>
>> Now, I tried again with the latest vm/image version and I get this error
>>
>> LGit_GIT_ERROR: username does not match previous request'
>>
>> Any idea ?
>>
>>
>
> I used my git username in the ssh settings.
> If I use "git" as username for the ssh setting, it complains about
> failed to authenticate SSH session
>
> How do other windows users use all this for pharo 7, any windows user how
> can write a little howto ?
>
>

Any news on howto use iceberg / libgit on windows.
Does no one else use windows ?

Re: [Pharo-dev] Pharo 7 provisional HOWTO

[Nicolai Hess]

2017-07-28 23:13 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:

>
>
> 2017-07-24 9:45 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>
>>
>>
>> 2017-07-11 12:46 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>>
>>>
>>>
>>> 2017-07-11 12:44 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>>>
>>>>
>>>>
>>>> 2017-07-11 12:28 GMT+02:00 Pavel Krivanek <pavel.kriva...@gmail.com>:
>>>>
>>>>> What is the system you use?
>>>>> AFAIK Esteban is fixing the latest Iceberg because it stopped to work
>>>>> on Windows...
>>>>>
>>>>> -- Pavel
>>>>>
>>>>
>>>> windows 10 32 bit
>>>>
>>>
>>> and on another windows 10 64  bit system
>>>
>>> on both, it crashes on working with libgit/iceberg
>>>
>>
>>
>> Any news ?
>> Anyone got a working libgit/iceberg for windows 32 or windows 64 ?
>>
>> Or is there any other way to be up to date with fixes, doing reviews and
>> bug fixes (without using github in the web browser) ?
>>
>
> Now, I tried again with the latest vm/image version and I get this error
>
> LGit_GIT_ERROR: username does not match previous request'
>
> Any idea ?
>
>

I used my git username in the ssh settings.
If I use "git" as username for the ssh setting, it complains about
failed to authenticate SSH session

How do other windows users use all this for pharo 7, any windows user how
can write a little howto ?

Re: [Pharo-dev] Pharo 7 provisional HOWTO

[Nicolai Hess]

2017-07-24 9:45 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:

>
>
> 2017-07-11 12:46 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>
>>
>>
>> 2017-07-11 12:44 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>>
>>>
>>>
>>> 2017-07-11 12:28 GMT+02:00 Pavel Krivanek <pavel.kriva...@gmail.com>:
>>>
>>>> What is the system you use?
>>>> AFAIK Esteban is fixing the latest Iceberg because it stopped to work
>>>> on Windows...
>>>>
>>>> -- Pavel
>>>>
>>>
>>> windows 10 32 bit
>>>
>>
>> and on another windows 10 64  bit system
>>
>> on both, it crashes on working with libgit/iceberg
>>
>
>
> Any news ?
> Anyone got a working libgit/iceberg for windows 32 or windows 64 ?
>
> Or is there any other way to be up to date with fixes, doing reviews and
> bug fixes (without using github in the web browser) ?
>

Now, I tried again with the latest vm/image version and I get this error

LGit_GIT_ERROR: username does not match previous request'

Any idea ?



>
>
>>
>>
>>>
>>>
>>>>
>>>> 2017-07-10 22:01 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>>>>
>>>>>
>>>>>
>>>>> 2017-07-03 23:17 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>>>>>
>>>>>>
>>>>>>
>>>>>> 2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>:
>>>>>>
>>>>>>>
>>>>>>> On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaih...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> And if I only want to contribute by reviewing a fix. Do I have to go
>>>>>>> the git-path ?
>>>>>>> Or is there a way to just start up an image and load and review the
>>>>>>> change?
>>>>>>>
>>>>>>>
>>>>>>> right now, you can review by going to github and seeing.
>>>>>>> I will add a “PR tool” to view/load PRs into an image, but that’s
>>>>>>> not ready. If someone wants to take a hit on it… the idea is to extend 
>>>>>>> the
>>>>>>> github plugin with it :)
>>>>>>>
>>>>>>> cheers!
>>>>>>> Esteban
>>>>>>>
>>>>>>
>>>>>> Anyone got this working on windows (32) ?
>>>>>> I followed this guide, enabled the ssh key setting for iceberg.
>>>>>> But I still got the error :
>>>>>>
>>>>>> Image: Pharo7.0SNAPSHOT [Latest update: #0]
>>>>>>
>>>>>> LGitReturnCodeEnum>>handleLGitReturnCode
>>>>>> Receiver: a LGitReturnCodeEnum(#git_error [-1])
>>>>>> Arguments and temporary variables:
>>>>>> handler: LGit_GIT_ERROR
>>>>>> Receiver's instance variables:
>>>>>> value: -1
>>>>>>
>>>>>>
>>>>>> LGitRepository(LGitExternalObject)>>withReturnHandlerDo:
>>>>>> Receiver: a LGitRepository ()
>>>>>> Arguments and temporary variables:
>>>>>> callBlock: [ self
>>>>>> clone: self
>>>>>> url: aString
>>>>>> local_path: aFileReference pathSt...etc...
>>>>>> Receiver's instance variables:
>>>>>> handle: @ 16r
>>>>>> repositoryPath: File @ pharo-core
>>>>>> isOpen: nil
>>>>>> workingDirectory: nil
>>>>>>
>>>>>>
>>>>>> LGitRepository>>clone:options:to:
>>>>>> Receiver: a LGitRepository ()
>>>>>> Arguments and temporary variables:
>>>>>> aString: 'g...@github.com:pharo-project/pharo.git'
>>>>>> cloneOptions: a LGitCloneOptions ()
>>>>>> aFileReference: File @ pharo-core
>>>>>> Receiver's instance variables:
>>>>>> handle: @ 16r
>>>>>> repositoryPath: File @ pharo-core
>>>>>> isOpen: nil
>>>>>> workingD

[Pharo-dev] iceberg / libgit behind proxy

[Nicolai Hess]

Anyone got it working to use iceberg /libgit behind a proxy?

I can access monticello repositories with the right proxy settings.
But using iceberg shows an error about
can not access github.org

Re: [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

[Nicolai Hess]

2017-07-26 16:42 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:

>
>
> 2017-07-26 16:25 GMT+02:00 Stephane Ducasse <stepharo.s...@gmail.com>:
>
>> I imagine that hot-fixes means when we found a serious bug in the
>> alpha version and see that it is also in the previous version.
>>
>> Now Hilaire if you want a change to be integrated in Pharo and Pharo
>> 60 for example.
>>
>> - we should have a bug entry on fogbugz (you see when I read the
>> emails I do not see the bug entry
>> so I have to look for it and lose time - because crawling the bug
>> database is tedious, so this is a lot more efficient to send also bug
>> entries).
>> - we should have a fix.
>> - it should be tagged for Pharo 60.
>> - it should be validated (pass the tests).
>>
>> Each time we introduce a fix, we may break sometimes so we pay really
>> attention to have
>> limited fixes with limited impact.
>>
>> For the ones you mentioned:
>>
>> - I cannot find the PNGReader bug entry. I read all the mails of the
>> thread.
>> So this is not efficient.
>>
>> - https://pharo.fogbugz.com/f/cases/20166/ is there but there is no
>> fix so we will have
>>
>
> The problem with fixes for Athens is, that nobody could tell we what the
> current state is.
>
> http://forum.world.st/current-athens-configuration-td4914441.html#a4914488
>
> the latest changes are from alexej and I guess they are important for
> sparta and the further development for bloc/sparte for pharo 7/8
> We can not just take the latest version and put it in pharo 6, and hope
> that it will work.
> We need for this external package a good communication about changes and
> versions.
> This did not happen here. And I am not sure if we maybe already put some
> changes in pharo 6, that are not at the athens repository.
> I once considered athens as an important package for the new pharo ui, but
> the way it is handled now looks more like abandoned.
>
> that is the reason why I just put the fix for 20166 in the comment of the
> bug entry instead of providing a slice / or update the version on the
> repository.
>
>
> It is ok if we tell hilaire to not just put bugreports on the ml but
> create a bug report on fogbugz instead. So people can fix/provide a slice
> and run the validation.
> But this happend in this case. It is just that we do not get it right to
> handle this case because it depens on athens.
>


whatever, put a slice for this case into the inbox
SLICE-Issue-20166-wrong-cliprect-on-transformed-athens-canvas-NicolaiHess.1

>
>
>
>>
>> People are nice and trying to help now everybody has its own agenda
>> and we set these "rules"
>> to avoid that we all lose time. If you want that people help you then
>> try to adhere to such best
>> practices.
>>
>> Follow the Pharo process.
>>
>> Stef.
>>
>>
>> On Tue, Jul 25, 2017 at 6:01 PM, Hilaire <hila...@drgeo.eu> wrote:
>> > Hi,
>> >
>> > It is the other minor bugs fixes details which were missing.
>> >
>> > What is hot-fixes?
>> >
>> > Hilaire
>> >
>> >
>> > --
>> > Dr. Geo
>> > http://drgeo.eu
>> >
>> >
>> >
>>
>>
>

Re: [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

[Nicolai Hess]

2017-07-26 16:25 GMT+02:00 Stephane Ducasse :

> I imagine that hot-fixes means when we found a serious bug in the
> alpha version and see that it is also in the previous version.
>
> Now Hilaire if you want a change to be integrated in Pharo and Pharo
> 60 for example.
>
> - we should have a bug entry on fogbugz (you see when I read the
> emails I do not see the bug entry
> so I have to look for it and lose time - because crawling the bug
> database is tedious, so this is a lot more efficient to send also bug
> entries).
> - we should have a fix.
> - it should be tagged for Pharo 60.
> - it should be validated (pass the tests).
>
> Each time we introduce a fix, we may break sometimes so we pay really
> attention to have
> limited fixes with limited impact.
>
> For the ones you mentioned:
>
> - I cannot find the PNGReader bug entry. I read all the mails of the
> thread.
> So this is not efficient.
>
> - https://pharo.fogbugz.com/f/cases/20166/ is there but there is no
> fix so we will have
>

The problem with fixes for Athens is, that nobody could tell we what the
current state is.

http://forum.world.st/current-athens-configuration-td4914441.html#a4914488

the latest changes are from alexej and I guess they are important for
sparta and the further development for bloc/sparte for pharo 7/8
We can not just take the latest version and put it in pharo 6, and hope
that it will work.
We need for this external package a good communication about changes and
versions.
This did not happen here. And I am not sure if we maybe already put some
changes in pharo 6, that are not at the athens repository.
I once considered athens as an important package for the new pharo ui, but
the way it is handled now looks more like abandoned.

that is the reason why I just put the fix for 20166 in the comment of the
bug entry instead of providing a slice / or update the version on the
repository.


It is ok if we tell hilaire to not just put bugreports on the ml but create
a bug report on fogbugz instead. So people can fix/provide a slice and run
the validation.
But this happend in this case. It is just that we do not get it right to
handle this case because it depens on athens.



>
> People are nice and trying to help now everybody has its own agenda
> and we set these "rules"
> to avoid that we all lose time. If you want that people help you then
> try to adhere to such best
> practices.
>
> Follow the Pharo process.
>
> Stef.
>
>
> On Tue, Jul 25, 2017 at 6:01 PM, Hilaire  wrote:
> > Hi,
> >
> > It is the other minor bugs fixes details which were missing.
> >
> > What is hot-fixes?
> >
> > Hilaire
> >
> >
> > --
> > Dr. Geo
> > http://drgeo.eu
> >
> >
> >
>
>

Re: [Pharo-dev] Pharo 7 provisional HOWTO

[Nicolai Hess]

2017-07-11 12:46 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:

>
>
> 2017-07-11 12:44 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>
>>
>>
>> 2017-07-11 12:28 GMT+02:00 Pavel Krivanek <pavel.kriva...@gmail.com>:
>>
>>> What is the system you use?
>>> AFAIK Esteban is fixing the latest Iceberg because it stopped to work on
>>> Windows...
>>>
>>> -- Pavel
>>>
>>
>> windows 10 32 bit
>>
>
> and on another windows 10 64  bit system
>
> on both, it crashes on working with libgit/iceberg
>


Any news ?
Anyone got a working libgit/iceberg for windows 32 or windows 64 ?

Or is there any other way to be up to date with fixes, doing reviews and
bug fixes (without using github in the web browser) ?


>
>
>>
>>
>>>
>>> 2017-07-10 22:01 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>>>
>>>>
>>>>
>>>> 2017-07-03 23:17 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>>>>
>>>>>
>>>>>
>>>>> 2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>:
>>>>>
>>>>>>
>>>>>> On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaih...@gmail.com> wrote:
>>>>>>
>>>>>> And if I only want to contribute by reviewing a fix. Do I have to go
>>>>>> the git-path ?
>>>>>> Or is there a way to just start up an image and load and review the
>>>>>> change?
>>>>>>
>>>>>>
>>>>>> right now, you can review by going to github and seeing.
>>>>>> I will add a “PR tool” to view/load PRs into an image, but that’s not
>>>>>> ready. If someone wants to take a hit on it… the idea is to extend the
>>>>>> github plugin with it :)
>>>>>>
>>>>>> cheers!
>>>>>> Esteban
>>>>>>
>>>>>
>>>>> Anyone got this working on windows (32) ?
>>>>> I followed this guide, enabled the ssh key setting for iceberg.
>>>>> But I still got the error :
>>>>>
>>>>> Image: Pharo7.0SNAPSHOT [Latest update: #0]
>>>>>
>>>>> LGitReturnCodeEnum>>handleLGitReturnCode
>>>>> Receiver: a LGitReturnCodeEnum(#git_error [-1])
>>>>> Arguments and temporary variables:
>>>>> handler: LGit_GIT_ERROR
>>>>> Receiver's instance variables:
>>>>> value: -1
>>>>>
>>>>>
>>>>> LGitRepository(LGitExternalObject)>>withReturnHandlerDo:
>>>>> Receiver: a LGitRepository ()
>>>>> Arguments and temporary variables:
>>>>> callBlock: [ self
>>>>> clone: self
>>>>> url: aString
>>>>> local_path: aFileReference pathSt...etc...
>>>>> Receiver's instance variables:
>>>>> handle: @ 16r
>>>>> repositoryPath: File @ pharo-core
>>>>> isOpen: nil
>>>>> workingDirectory: nil
>>>>>
>>>>>
>>>>> LGitRepository>>clone:options:to:
>>>>> Receiver: a LGitRepository ()
>>>>> Arguments and temporary variables:
>>>>> aString: 'g...@github.com:pharo-project/pharo.git'
>>>>> cloneOptions: a LGitCloneOptions ()
>>>>> aFileReference: File @ pharo-core
>>>>> Receiver's instance variables:
>>>>> handle: @ 16r
>>>>> repositoryPath: File @ pharo-core
>>>>> isOpen: nil
>>>>> workingDirectory: nil
>>>>>
>>>>>
>>>>> And finally after some more tries, the vm crashed
>>>>> (crash.dmp attached).
>>>>>
>>>>> If this only happens on windows, what else would be an option to start
>>>>> with contributing for pharo 7 ?
>>>>>
>>>>
>>>> maybe I am doing something wrong ? I thought this should work now with
>>>> the latest vm (and libgit)?
>>>> It is still crashing for me.
>>>>
>>>> [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class
>>>> failed
>>>> [0mExternalAdd

Re: [Pharo-dev] PharoSpur32Vm

[Nicolai Hess]

2017-07-23 22:38 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com>:

>
>
> 2017-07-23 19:56 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>
>>
>>
>> 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 <nicolaih...@gmail.com>:
>>> >
>>> > 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 

Re: [Pharo-dev] PharoSpur32Vm

[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 <nicolaih...@gmail.com>:
> >
> > 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/
> bin:/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 ?



>
> Hernán
>
> >
> > nicolai
> >
> >
> >
> > 2017-03-15 10:11 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:
> >>
> >>
> >>
> >> 2017-03-15 9:22 GMT+01:00 philippe.b...@highoctane.be <
> philippe.b...@gmail.com>:
> >>>
> >>> 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.
> >>
> >>
> >> Ah good, thank you.
> >>
> >>
> >>>
> >>>
> >>> HTH
> >>>
> >>> Phil
> >>>
> >>> Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaih...@gmail.com> a écrit
> :
> >>>>
> >>>>
> >>>>
> >>>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com>:
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com>:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> 2017-03-11 10:01 GMT+01:00 Nicolas 

Re: [Pharo-dev] PharoSpur32Vm

[Nicolai Hess]

2017-07-22 20:26 GMT+02:00 Eliot Miranda <eliot.mira...@gmail.com>:

> Hi Nicolai,
>
>
> On Jul 22, 2017, at 6:03 AM, Nicolai Hess <nicolaih...@gmail.com> wrote:
>
> 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",
>
>
> There isn't a configure script.  The choice of which compiler to make,
> flags to use etc is made in
> build.win32x86/common/Makefile.rules
> build.win32x86/common/Makefile.tools
> and should be able to be overridden by editing
>  build.win32x86/pharo.cog.spur/Makefile
>


The configure script is used by third party libs (for pharo only
(pk-config)).



>
>
> again, this seems to work on the appveyor build but not locally on my
> machine.
>
> Any idea what I had missed?
>
>
> nicolai
>
>
>
> 2017-03-15 10:11 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:
>
>>
>>
>> 2017-03-15 9:22 GMT+01:00 philippe.b...@highoctane.be <
>> philippe.b...@gmail.com>:
>>
>>> 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.
>>>
>>
>> Ah good, thank you.
>>
>>
>>
>>>
>>> HTH
>>>
>>> Phil
>>>
>>> Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaih...@gmail.com> a écrit :
>>>
>>>>
>>>>
>>>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier <
>>>> nicolas.cellier.aka.n...@gmail.com>:
>>>>
>>>>>
>>>>>
>>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <
>>>>> nicolas.cellier.aka.n...@gmail.com>:
>>>>>
>>>>>>
>>>>>>
>>>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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

Re: [Pharo-dev] PharoSpur32Vm

[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?


nicolai



2017-03-15 10:11 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:

>
>
> 2017-03-15 9:22 GMT+01:00 philippe.b...@highoctane.be <
> philippe.b...@gmail.com>:
>
>> 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.
>>
>
> Ah good, thank you.
>
>
>
>>
>> HTH
>>
>> Phil
>>
>> Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaih...@gmail.com> a écrit :
>>
>>>
>>>
>>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier <
>>> nicolas.cellier.aka.n...@gmail.com>:
>>>
>>>>
>>>>
>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <
>>>> nicolas.cellier.aka.n...@gmail.com>:
>>>>
>>>>>
>>>>>
>>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:
>>>>>
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>

Re: [Pharo-dev] Pharo 7 provisional HOWTO

[Nicolai Hess]

2017-07-11 12:44 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:

>
>
> 2017-07-11 12:28 GMT+02:00 Pavel Krivanek <pavel.kriva...@gmail.com>:
>
>> What is the system you use?
>> AFAIK Esteban is fixing the latest Iceberg because it stopped to work on
>> Windows...
>>
>> -- Pavel
>>
>
> windows 10 32 bit
>

and on another windows 10 64  bit system

on both, it crashes on working with libgit/iceberg


>
>
>>
>> 2017-07-10 22:01 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>>
>>>
>>>
>>> 2017-07-03 23:17 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>>>
>>>>
>>>>
>>>> 2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>:
>>>>
>>>>>
>>>>> On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaih...@gmail.com> wrote:
>>>>>
>>>>> And if I only want to contribute by reviewing a fix. Do I have to go
>>>>> the git-path ?
>>>>> Or is there a way to just start up an image and load and review the
>>>>> change?
>>>>>
>>>>>
>>>>> right now, you can review by going to github and seeing.
>>>>> I will add a “PR tool” to view/load PRs into an image, but that’s not
>>>>> ready. If someone wants to take a hit on it… the idea is to extend the
>>>>> github plugin with it :)
>>>>>
>>>>> cheers!
>>>>> Esteban
>>>>>
>>>>
>>>> Anyone got this working on windows (32) ?
>>>> I followed this guide, enabled the ssh key setting for iceberg.
>>>> But I still got the error :
>>>>
>>>> Image: Pharo7.0SNAPSHOT [Latest update: #0]
>>>>
>>>> LGitReturnCodeEnum>>handleLGitReturnCode
>>>> Receiver: a LGitReturnCodeEnum(#git_error [-1])
>>>> Arguments and temporary variables:
>>>> handler: LGit_GIT_ERROR
>>>> Receiver's instance variables:
>>>> value: -1
>>>>
>>>>
>>>> LGitRepository(LGitExternalObject)>>withReturnHandlerDo:
>>>> Receiver: a LGitRepository ()
>>>> Arguments and temporary variables:
>>>> callBlock: [ self
>>>> clone: self
>>>> url: aString
>>>> local_path: aFileReference pathSt...etc...
>>>> Receiver's instance variables:
>>>> handle: @ 16r
>>>> repositoryPath: File @ pharo-core
>>>> isOpen: nil
>>>> workingDirectory: nil
>>>>
>>>>
>>>> LGitRepository>>clone:options:to:
>>>> Receiver: a LGitRepository ()
>>>> Arguments and temporary variables:
>>>> aString: 'g...@github.com:pharo-project/pharo.git'
>>>> cloneOptions: a LGitCloneOptions ()
>>>> aFileReference: File @ pharo-core
>>>> Receiver's instance variables:
>>>> handle: @ 16r
>>>> repositoryPath: File @ pharo-core
>>>> isOpen: nil
>>>> workingDirectory: nil
>>>>
>>>>
>>>> And finally after some more tries, the vm crashed
>>>> (crash.dmp attached).
>>>>
>>>> If this only happens on windows, what else would be an option to start
>>>> with contributing for pharo 7 ?
>>>>
>>>
>>> maybe I am doing something wrong ? I thought this should work now with
>>> the latest vm (and libgit)?
>>> It is still crashing for me.
>>>
>>> [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed
>>> [0mExternalAddress class(Object)>>primitiveFailed:
>>> ExternalAddress class(Object)>>primitiveFailed
>>> ExternalAddress class>>allocate:
>>> LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew
>>> LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults
>>> LGitRemoteCallbacks class>>defaults
>>> LGitRemoteCallbacks class>>withProvider:
>>> LGitCloneOptions class>>withCredentialsProvider:
>>> [ | repo cloneOptions |
>>> repo := LGitRepository on: self location.
>>> cloneOptions := LGitCloneOptions
>>> withCredentialsProvider: IceCredentialsProvider default.
>>> 

Re: [Pharo-dev] Pharo 7 provisional HOWTO

[Nicolai Hess]

2017-07-11 12:28 GMT+02:00 Pavel Krivanek <pavel.kriva...@gmail.com>:

> What is the system you use?
> AFAIK Esteban is fixing the latest Iceberg because it stopped to work on
> Windows...
>
> -- Pavel
>

windows 10 32 bit


>
> 2017-07-10 22:01 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>
>>
>>
>> 2017-07-03 23:17 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:
>>
>>>
>>>
>>> 2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>:
>>>
>>>>
>>>> On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaih...@gmail.com> wrote:
>>>>
>>>> And if I only want to contribute by reviewing a fix. Do I have to go
>>>> the git-path ?
>>>> Or is there a way to just start up an image and load and review the
>>>> change?
>>>>
>>>>
>>>> right now, you can review by going to github and seeing.
>>>> I will add a “PR tool” to view/load PRs into an image, but that’s not
>>>> ready. If someone wants to take a hit on it… the idea is to extend the
>>>> github plugin with it :)
>>>>
>>>> cheers!
>>>> Esteban
>>>>
>>>
>>> Anyone got this working on windows (32) ?
>>> I followed this guide, enabled the ssh key setting for iceberg.
>>> But I still got the error :
>>>
>>> Image: Pharo7.0SNAPSHOT [Latest update: #0]
>>>
>>> LGitReturnCodeEnum>>handleLGitReturnCode
>>> Receiver: a LGitReturnCodeEnum(#git_error [-1])
>>> Arguments and temporary variables:
>>> handler: LGit_GIT_ERROR
>>> Receiver's instance variables:
>>> value: -1
>>>
>>>
>>> LGitRepository(LGitExternalObject)>>withReturnHandlerDo:
>>> Receiver: a LGitRepository ()
>>> Arguments and temporary variables:
>>> callBlock: [ self
>>> clone: self
>>> url: aString
>>> local_path: aFileReference pathSt...etc...
>>> Receiver's instance variables:
>>> handle: @ 16r
>>> repositoryPath: File @ pharo-core
>>> isOpen: nil
>>> workingDirectory: nil
>>>
>>>
>>> LGitRepository>>clone:options:to:
>>> Receiver: a LGitRepository ()
>>> Arguments and temporary variables:
>>> aString: 'g...@github.com:pharo-project/pharo.git'
>>> cloneOptions: a LGitCloneOptions ()
>>> aFileReference: File @ pharo-core
>>> Receiver's instance variables:
>>> handle: @ 16r
>>> repositoryPath: File @ pharo-core
>>> isOpen: nil
>>> workingDirectory: nil
>>>
>>>
>>> And finally after some more tries, the vm crashed
>>> (crash.dmp attached).
>>>
>>> If this only happens on windows, what else would be an option to start
>>> with contributing for pharo 7 ?
>>>
>>
>> maybe I am doing something wrong ? I thought this should work now with
>> the latest vm (and libgit)?
>> It is still crashing for me.
>>
>> [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed
>> [0mExternalAddress class(Object)>>primitiveFailed:
>> ExternalAddress class(Object)>>primitiveFailed
>> ExternalAddress class>>allocate:
>> LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew
>> LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults
>> LGitRemoteCallbacks class>>defaults
>> LGitRemoteCallbacks class>>withProvider:
>> LGitCloneOptions class>>withCredentialsProvider:
>> [ | repo cloneOptions |
>> repo := LGitRepository on: self location.
>> cloneOptions := LGitCloneOptions
>> withCredentialsProvider: IceCredentialsProvider default.
>> repo clone: url options: cloneOptions.
>> aBranchName ifNotNil: [ repo checkout: aBranchName ].
>> (LGitRemote of: repo named: 'origin')
>> lookup;
>> setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch:
>> in Block: [ | repo cloneOptions |...
>> [ self checkInitialized.
>> [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed
>> [0mExternalAddress class(Object)>>primitiveFailed:
>> ExternalAddress class(Object)>>primitiveFailed
>> ExternalAddress class>>allocate:
>> LGitRemoteCallba

Re: [Pharo-dev] Pharo 7 provisional HOWTO

[Nicolai Hess]

2017-07-03 23:17 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>:

>
>
> 2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>:
>
>>
>> On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaih...@gmail.com> wrote:
>>
>> And if I only want to contribute by reviewing a fix. Do I have to go the
>> git-path ?
>> Or is there a way to just start up an image and load and review the
>> change?
>>
>>
>> right now, you can review by going to github and seeing.
>> I will add a “PR tool” to view/load PRs into an image, but that’s not
>> ready. If someone wants to take a hit on it… the idea is to extend the
>> github plugin with it :)
>>
>> cheers!
>> Esteban
>>
>
> Anyone got this working on windows (32) ?
> I followed this guide, enabled the ssh key setting for iceberg.
> But I still got the error :
>
> Image: Pharo7.0SNAPSHOT [Latest update: #0]
>
> LGitReturnCodeEnum>>handleLGitReturnCode
> Receiver: a LGitReturnCodeEnum(#git_error [-1])
> Arguments and temporary variables:
> handler: LGit_GIT_ERROR
> Receiver's instance variables:
> value: -1
>
>
> LGitRepository(LGitExternalObject)>>withReturnHandlerDo:
> Receiver: a LGitRepository ()
> Arguments and temporary variables:
> callBlock: [ self
> clone: self
> url: aString
> local_path: aFileReference pathSt...etc...
> Receiver's instance variables:
> handle: @ 16r
> repositoryPath: File @ pharo-core
> isOpen: nil
> workingDirectory: nil
>
>
> LGitRepository>>clone:options:to:
> Receiver: a LGitRepository ()
> Arguments and temporary variables:
> aString: 'g...@github.com:pharo-project/pharo.git'
> cloneOptions: a LGitCloneOptions ()
> aFileReference: File @ pharo-core
> Receiver's instance variables:
> handle: @ 16r
> repositoryPath: File @ pharo-core
> isOpen: nil
> workingDirectory: nil
>
>
> And finally after some more tries, the vm crashed
> (crash.dmp attached).
>
> If this only happens on windows, what else would be an option to start
> with contributing for pharo 7 ?
>

maybe I am doing something wrong ? I thought this should work now with the
latest vm (and libgit)?
It is still crashing for me.

[31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed
[0mExternalAddress class(Object)>>primitiveFailed:
ExternalAddress class(Object)>>primitiveFailed
ExternalAddress class>>allocate:
LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew
LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults
LGitRemoteCallbacks class>>defaults
LGitRemoteCallbacks class>>withProvider:
LGitCloneOptions class>>withCredentialsProvider:
[ | repo cloneOptions |
repo := LGitRepository on: self location.
cloneOptions := LGitCloneOptions
withCredentialsProvider: IceCredentialsProvider default.
repo clone: url options: cloneOptions.
aBranchName ifNotNil: [ repo checkout: aBranchName ].
(LGitRemote of: repo named: 'origin')
lookup;
setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch:
in Block: [ | repo cloneOptions |...
[ self checkInitialized.
[31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed
[0mExternalAddress class(Object)>>primitiveFailed:
ExternalAddress class(Object)>>primitiveFailed
ExternalAddress class>>allocate:
LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew
LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults
LGitRemoteCallbacks class>>defaults
LGitRemoteCallbacks class>>withProvider:
LGitCloneOptions class>>withCredentialsProvider:
[ | repo cloneOptions |
repo := LGitRepository on: self location.
cloneOptions := LGitCloneOptions
withCredentialsProvider: IceCredentialsProvider default.
repo clone: url options: cloneOptions.
aBranchName ifNotNil: [ repo checkout: aBranchName ].
(LGitRemote of: repo named: 'origin')
lookup;
setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch:
in Block: [ | repo cloneOptions |...
[ self checkInitialized.
aBlock value ] in LGitGlobal class>>runSequence: in Block: [ self
checkInitialized
[ activeProcess psValueAt: index put: anObject.
aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: in
Block: [ activeProcess psValueAt: index put: anObject
BlockClosure>>ensure:
LGitActionSequence(DynamicVariable)>>value:during:
LGitActionSequence class(DynamicVariable class)>>value:during:
LGitGlobal class>>runSequence:
IceL

Re: [Pharo-dev] No Metadata in 7.0

[Nicolai Hess]

2017-07-10 11:22 GMT+02:00 Alistair Grant <akgrant0...@gmail.com>:

> On Mon, Jul 10, 2017 at 11:15:27AM +0200, Nicolai Hess wrote:
> >
> > 2017-07-10 10:31 GMT+02:00 Pavel Krivanek <pavel.kriva...@gmail.com>:
> >
> > However the real question is if we need them in the form we had them
> until
> > now because they are flattened as soon as a new changes file
> (release) is
> > created and it stores only information about the last person who
> touched
> > the method, not about the author nor wider history.
> >
> > For me, YES!
> >
> > I always take this data as a hint to track down bugs. Especially in
> > this community were different people do bug fixes or introduce
> > something new /change something, it is really helpfull and valueable
> > to track this changes by the method history. (not only *who* did the
> > change, but also, in what context, what else had changed.  And I think
> > it is much easier to do this from within the image instead of looking
> > at the git diff).
>
> Are the two really mutually exclusive?  Given the move to Iceberg
> wouldn't it make sense to extend Iceberg to be able to analyse the git
> history from within the image?
>


No, they are not mutually exclusive, it is just that you can not see the
history now.
Maybe iceberg will solve this, but for now you can not see the history
 (and as a windows user, I can not even use iceberg).



>
>
> > That hte history is already lost when we created a new changes/sources
> > for release is something that always disturbed me. And I hoped there
> > would be some way to reload the "real" history with all intermediate
> > changes.
>
> Cheers,
> Alistair
>
>
>

Re: [Pharo-dev] No Metadata in 7.0

[Nicolai Hess]

2017-07-10 10:31 GMT+02:00 Pavel Krivanek :

>
>
> However the real question is if we need them in the form we had them until
> now because they are flattened as soon as a new changes file (release) is
> created and it stores only information about the last person who touched
> the method, not about the author nor wider history.
>

For me, YES!
I always take this data as a hint to track down bugs. Especially in this
community were different people do bug fixes or introduce something new
/change something,
it is really helpfull and valueable to track this changes by the method
history. (not only *who* did the change, but also, in what context, what
else had changed.
And I think it is much easier to do this from within the image instead of
looking at the git diff).

That hte history is already lost when we created a new changes/sources for
release is something that always disturbed me. And I hoped there would be
some
way to reload the "real" history with all intermediate changes.



>
>
>
>
>
> 2017-07-10 10:15 GMT+02:00 Guillermo Polito :
>
>>
>>
>> On Sun, Jul 9, 2017 at 10:10 PM, Henrik Nergaard 
>> wrote:
>>
>>> Hi,
>>>
>>> I had a look at the Pharo 7.0 today and see metadata for methods (Author
>>> and timestamp) has been removed*, what is the reason for this?
>>>
>>> Having the ability to find methods created around the same time and/or
>>> by author is quite useful when fixing bugs in the core libraries.
>>>
>>> There is also quite a lot of history that is lost as well with this
>>> change (I am always impressed when I stumble upon methods over 15-20 years
>>> old!).
>>>
>>>
>>>
>>> Could this be reverted, please?
>>>
>>> [*] all methods have a stamp, but it is the same for all with only a
>>> timestamp from the bootstrap(?).
>>>
>>>
>> Hi Henrik,
>>
>> I'm sorry about that, it's probably a side effect of the bootstrap. We
>> may have to track down the cause, so if you can help, it's most welcome :).
>> For that I can explain you the process as it is today:
>>
>>  1st) We previously exported all code from Pharo to FileTree
>> (Metadataless I think). This step is not done anymore.
>>  2nd) We bootstrap from the packages on FileTree by first compiling
>> methods without metadata.
>>
>>  3rd) We export all bootstrap packages from filetree to MCZ
>>
>> https://github.com/pharo-project/pharo/blob/development/
>> bootstrap/src/Pharo30Bootstrap.package/PBBootstrap.class/
>> instance/exportAllPackagesIntoMcz.st
>>
>>  4th) Once the first image is ready (without source code nor meta-data)
>> we install monticello and we reload all mcz files
>> This regenerates the source code and should load all metadata in
>> mczs
>>
>> https://github.com/pharo-project/pharo/blob/development/
>> bootstrap/scripts/02-monticello-bootstrap/02-bootstrapMonticello.st
>>
>> So either it is that the metadata is lost in Filetree because it is
>> metadataless, or it is lost in the intermediate conversion to mcz, or in
>> the loading.
>>
>> Guille
>>
>>
>>>
>>>
>>> Best regards,
>>>
>>> Henrik
>>>
>>>
>>
>>
>> --
>>
>>
>>
>> Guille Polito
>>
>>
>> Research Engineer
>>
>> French National Center for Scientific Research - *http://www.cnrs.fr*
>> 
>>
>>
>>
>> *Web:* *http://guillep.github.io* 
>>
>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>>
>
>

Re: [Pharo-dev] Pharo 7 provisional HOWTO

[Nicolai Hess]

2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>:

>
> On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaih...@gmail.com> wrote:
>
> And if I only want to contribute by reviewing a fix. Do I have to go the
> git-path ?
> Or is there a way to just start up an image and load and review the change?
>
>
> right now, you can review by going to github and seeing.
> I will add a “PR tool” to view/load PRs into an image, but that’s not
> ready. If someone wants to take a hit on it… the idea is to extend the
> github plugin with it :)
>
> cheers!
> Esteban
>

Anyone got this working on windows (32) ?
I followed this guide, enabled the ssh key setting for iceberg.
But I still got the error :

Image: Pharo7.0SNAPSHOT [Latest update: #0]

LGitReturnCodeEnum>>handleLGitReturnCode
Receiver: a LGitReturnCodeEnum(#git_error [-1])
Arguments and temporary variables:
handler: LGit_GIT_ERROR
Receiver's instance variables:
value: -1


LGitRepository(LGitExternalObject)>>withReturnHandlerDo:
Receiver: a LGitRepository ()
Arguments and temporary variables:
callBlock: [ self
clone: self
url: aString
local_path: aFileReference pathSt...etc...
Receiver's instance variables:
handle: @ 16r
repositoryPath: File @ pharo-core
isOpen: nil
workingDirectory: nil


LGitRepository>>clone:options:to:
Receiver: a LGitRepository ()
Arguments and temporary variables:
aString: 'g...@github.com:pharo-project/pharo.git'
cloneOptions: a LGitCloneOptions ()
aFileReference: File @ pharo-core
Receiver's instance variables:
handle: @ 16r
repositoryPath: File @ pharo-core
isOpen: nil
workingDirectory: nil


And finally after some more tries, the vm crashed
(crash.dmp attached).

If this only happens on windows, what else would be an option to start with
contributing for pharo 7 ?



>
>
> Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" <
> pavel.kriva...@gmail.com>:
>
>
>
> 2017-06-28 17:06 GMT+02:00 Clément Bera <bera.clem...@gmail.com>:
>
>> Hi all,
>>
>> Just to be clear, in Pharo 7, if I want to get some code integrated:
>> - I *have to* use the pull request process described by Pavel
>> OR
>> - I *can* use the pull request process, but I can also use the old slice
>> monticello process
>> ?
>>
>> What is the answer to the first question now, and what will be the answer
>> of this question in 6 months from now ?
>>
>
> You should use the pull request process.
>
> It is possible to create a standard slice BUT it must be done from Pharo 6
> and then sent into Pharo60Inbox. And then you need to wait until somebody
> converts this slice to pull request. That means that it will be harder and
> harder to contribute this way because the code-base is moving.
>
> No slice will be integrated into Pharo 7 with the old process directly.
>
> Cheers,
> -- Pavel
>
>
>
>>
>> Thanks
>>
>>
>> On Wed, Jun 28, 2017 at 3:42 PM, Ben Coman <b...@openinworld.com> wrote:
>>
>>>
>>>
>>> On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <juraj.kube...@icloud.com
>>> > wrote:
>>>
>>>>
>>>> El 28-06-2017, a las 02:57, Ben Coman <b...@openinworld.com> escribió:
>>>>
>>>>
>>>>
>>>> On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <
>>>> pavel.kriva...@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> 2017-06-27 16:17 GMT+02:00 Serge Stinckwich <
>>>>> serge.stinckw...@gmail.com>:
>>>>>
>>>>>> On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek
>>>>>> <pavel.kriva...@gmail.com> wrote:
>>>>>> >
>>>>>> >
>>>>>> > 2017-06-27 15:57 GMT+02:00 Serge Stinckwich <
>>>>>> serge.stinckw...@gmail.com>:
>>>>>> >>
>>>>>> >> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek
>>>>>> >> <pavel.kriva...@gmail.com> wrote:
>>>>>> >> > Hi,
>>>>>> >> >
>>>>>> >> > this mail describes how to start to send pull requests to Pharo
>>>>>> 7 Github
>>>>>> >> > repository from Pharo 7.
>>>>>> >>
>>>>>> >> Thank you for the great explanation Pavel.
>>>>>> >>
>>>

Re: [Pharo-dev] [Pharo-users] Custom Glamour browser for Dr. Geo scripting

[Nicolai Hess]

2017-06-30 9:55 GMT+02:00 Hilaire :

> I extended the browser definition with:
>
> browser transmit
> from: #scripts;
> from: #categories;
> to: #methods;
> when: [ :a :b |  a isMeta not ];
> andShow: [:a | self methodsIn: a  ].
> browser transmit
> from: #scripts;
> from: #categories;
> to: #methods;
> when: [ :a | a isMeta ];
> andShow: [:a | self classMethodsIn: a  ].
>
>
> However it does not work as #when: message always receive a class, so
> the wrong methods a re list in the method pane.
>
> I enclosed a Fileout of the browser. It works independently of DrGeo.
> When one select class methods, still the instance methods are displayed
> in right most pane.
>
> Any tips?
>

I don't have a solution. I just want to make more clear what the problem is.
See attached screenshot.
The question is, is it possible to make the population of the "methods" list
dependent of the focused "Instance Methods"/"Class Methods" pane ?

I tried to wire a "#focus" port, but I don't think the "categories"-pane
exports
any port that could be used to distinguish between the selected tabs.






>
> Thanks
>
> Hilaire
>
>
> Le 29/06/2017 à 14:59, Hilaire a écrit :
> > but something is missing to get the listed method right depending on the
> > category is instance or class side. I don't how to do it.
>
> --
> Dr. Geo
> http://drgeo.eu
>
>

Re: [Pharo-dev] Pharo 7 provisional HOWTO

[Nicolai Hess]

And if I only want to contribute by reviewing a fix. Do I have to go the
git-path ?
Or is there a way to just start up an image and load and review the change?

Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" :



2017-06-28 17:06 GMT+02:00 Clément Bera :

> Hi all,
>
> Just to be clear, in Pharo 7, if I want to get some code integrated:
> - I *have to* use the pull request process described by Pavel
> OR
> - I *can* use the pull request process, but I can also use the old slice
> monticello process
> ?
>
> What is the answer to the first question now, and what will be the answer
> of this question in 6 months from now ?
>

You should use the pull request process.

It is possible to create a standard slice BUT it must be done from Pharo 6
and then sent into Pharo60Inbox. And then you need to wait until somebody
converts this slice to pull request. That means that it will be harder and
harder to contribute this way because the code-base is moving.

No slice will be integrated into Pharo 7 with the old process directly.

Cheers,
-- Pavel



>
> Thanks
>
>
> On Wed, Jun 28, 2017 at 3:42 PM, Ben Coman  wrote:
>
>>
>>
>> On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka 
>> wrote:
>>
>>>
>>> El 28-06-2017, a las 02:57, Ben Coman  escribió:
>>>
>>>
>>>
>>> On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <
>>> pavel.kriva...@gmail.com> wrote:
>>>


 2017-06-27 16:17 GMT+02:00 Serge Stinckwich :

> On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek
>  wrote:
> >
> >
> > 2017-06-27 15:57 GMT+02:00 Serge Stinckwich <
> serge.stinckw...@gmail.com>:
> >>
> >> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek
> >>  wrote:
> >> > Hi,
> >> >
> >> > this mail describes how to start to send pull requests to Pharo 7
> Github
> >> > repository from Pharo 7.
> >>
> >> Thank you for the great explanation Pavel.
> >>
> >> > Preparations
> >> > =
> >> >
> >> > - you need to have a Github account and set SSH keys. See
> >> > https://help.github.com/articles/connecting-to-github-with-ssh/
> >> > - create own pharo-project/pharo repository fork. Go to
> >> > https://github.com/pharo-project/pharo, click on "Fork" button
> and
> >> > follow
> >> > the instructions
> >>
> >> [ ... ]
> >>
> >> > Issue processing
> >> > =
> >> >
> >> > - create new case on FogBugz to get the issue number
> >> > - open Iceberg and from the context menu on the 'pharo'
> repository do:
> >> > Pharo
> >> > - Create new branch from FogBugz issue, enter the issue ID and it
> will
> >> > fill
> >> > the full branch name for you
> >> > - create your changes (you can do it before the creation of the
> branch
> >> > too)
> >> > - commit and push your changes in Iceberg, this way you will
> commit your
> >> > branch to your fork repository. Remember that the Iceberg commit
> window
> >> > has
> >> > two buttons, one for local commit, the second for commit with
> immediate
> >> > push. They can be very long because they contain the full branch
> (issue)
> >> > name
> >> > - in Iceberg in the 'pharo' repository context menu do: Pharo -
> Create
> >> > pull
> >> > request, fill your
> >> > - fill your Github credentials
> >> > - leave the PR title, comment is not required, check the pull
> request
> >> > head
> >> > and base. The base MUST be pharo-project/pharo development.
> Create the
> >> > pull
> >> > requests
> >> > - go to https://github.com/pharo-project/pharo/pulls, check your
> pull
> >> > requests and put URL of it into the issue record on FogBugz (as a
> >> > comment).
> >> > Resolve the issue as Fix review needed
> >>
> >> It means, there is no PR without a corresponding FogBugz issue ?
> >
> >
> > Yes, at least for code changes we would like to keep this relation.
> If it is
> > a really trivial change in readme or something like that, we can
> accept no
> > related issue record.
> > Please prefer to comment the issues instead of PRs directly to have
> all
> > information at one place.
>
> Thank you Pavel for the explanation.
>
> Maybe in the future, it will make sense to put everything in the PR
> and use github issues.
> You will use CI travis builds for all PR ?
>

 For now we will use FogBugz because it has a lot of nice features and
 good API. Maybe we will switch it in future but now we should not change
 too many things at once :-)
 For several reasons we now prefer to use own infrastructure for
 checking of PRs 

[Pharo-dev] zero size pharo vm zips

[Nicolai Hess]

http://files.pharo.org/vm/pharo-spur32/win/

All vm-zips from the last days have size 0

Re: [Pharo-dev] Traits methods flattened

[Nicolai Hess]

2017-04-25 19:08 GMT+02:00 Hilaire <hila...@drgeo.eu>:

> Can you produce tests exposing these fails?
>

|set|
set := Set new.
Smalltalk allClassesAndTraits select:[:tc | tc traitComposition notEmpty]
thenDo:[:b | |tc nonLocal| tc:= b traits.
nonLocal :=
b localMethods select:[:m |
tc anySatisfy:[:t | t methods contains:[:tm|
((tm selector = m selector and:[tm bytecode = m bytecode])
and:[tm literals allButLast = m literals allButLast])]]].
nonLocal notEmpty ifTrue:[set addAll:( nonLocal)]].

MessageBrowser browse:set




>
> Hilaire
>
>
> Le 25/04/2017 à 10:47, Nicolai Hess a écrit :
> > Keep in mind.
> > 1. the way new trait methods are handled is still wrong
> >if non-local methods (methods from  a trait) aren't added to the
> > rpackage when creating the user of this trait, why are  new trait
> > methods "flattened" into this package
> > 2. we already have some "corrupted" (flattened) packages in the image.
> > (some methods of users of Traits are copied from the trait).
> > For example,
> > traits using the trait GLMBrickExtensionTrait or
> > test case traits using other traits (TRemoveForMultiplenessTest /
> > TRemoveTest, TDictionaryCopyingTest/TCloneTest)
> >
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>

Re: [Pharo-dev] spec ui as morph

[Nicolai Hess]

2017-04-26 12:00 GMT+02:00 Christophe Demarey :

> thanks but the result is not a morph.
>

Are you sure ?

(TextModel new text: Morph comment; buildWithSpec) openInHand -> a Morph


> Should I use yourModel buildWithSpec  spec instance?
>
> > Le 26 avr. 2017 à 11:55, Esteban Lorenzano  a
> écrit :
> >
> > yourModel buildWithSpec.
> >
> > Esteban
> >
> >> On 26 Apr 2017, at 11:51, Christophe Demarey <
> christophe.dema...@inria.fr> wrote:
> >>
> >> Hi,
> >>
> >> Does anyone know how to embed a UI component made with Spec into a UI
> expecting a morph?
> >> It looks like the only way to build a spec UI is to open it with
> #openWithSpec that will always embed the component in a window.
> >>
> >> Thanks,
> >> Christophe
> >
>
>
>

Re: [Pharo-dev] Traits methods flattened

[Nicolai Hess]

2017-04-25 10:12 GMT+02:00 Hilaire :

> Ah, no sorry. After another try I got it right, I have to unload the
> package then file it in again to get it right.
>
> So the fix work for my problem too, issue definitely fixed and closed.
>
> Thanks
>
>
Keep in mind.
1. the way new trait methods are handled is still wrong
   if non-local methods (methods from  a trait) aren't added to the
rpackage when creating the user of this trait, why are  new trait methods
"flattened" into this package
2. we already have some "corrupted" (flattened) packages in the image.
(some methods of users of Traits are copied from the trait).
For example,
traits using the trait GLMBrickExtensionTrait or
test case traits using other traits (TRemoveForMultiplenessTest /
TRemoveTest, TDictionaryCopyingTest/TCloneTest)


>
> Le 25/04/2017 à 09:37, Hilaire a écrit :
> > Is there a way I can test on a Pharo6 image, because the backport does
> > not fix my problem with Traits on Pharo5?
> >
> > I am reopening the ticket.
> >
> > Hilaire
> >
> >
> > Le 22/04/2017 à 16:42, Pavel Krivanek a écrit :
> >> backported:
> >> https://pharo.fogbugz.com/f/cases/19974/backport-Traits-
> methods-flattened-case-19938
> >>
> >> Test please...
> >> -- Pavel
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>

Re: [Pharo-dev] Implementers code pane undo goes too far

[Nicolai Hess]

2017-04-22 5:21 GMT+02:00 Ben Coman :

> This issue was introduced into build 50245 [1].  If no one has noticed
> before, its not critical for Pharo 6 (unless it exposes something that
> may bite others more widely.)
>

As far as I remember, there were a couple of issues (maybe autoclosed)
related to rubrics undo-behavior.
17601

bad undo behavior after discard changes

Some are fixed by a workaround (unset #hasUnacceptedEdits when new code is
loaded).




>
> Can reproduce by loading slice for Case 15774 on top of build 50244.
> "Make Spec using RubPluggableTextMorph instead of PluggableTextMorph "
>
> [1] http://forum.world.st/pharo-project-pharo-core-03b7d7-
> 50245-td4843802.html
>
> cheers -ben
>
> On Sat, Apr 22, 2017 at 10:54 AM, Ben Coman  wrote:
> > I hit some strange behaviour...
> >
> > Setup...
> > 1. In playground, type... green
> > 2. Open implementers on it
> > 3. Select the second line "Color class(defaults)green"
> > 4. Click in the code pane
> > Observe that "green" is pre-selected and the cursor is flashing at
> > end of first line
> > 5. Start typing... self halt.
> > Observe the method name is overwritten
> >
> > Problem...
> > 6. Hit CTRL-Z three times.
> > Observe the instance side #green is displayed rather than the class
> side.
> >
> > Auxiliary...
> > Now save it and work out how to get out of the mess
> > (pretending you didn't notice what had happened)
> >
> > https://pharo.fogbugz.com/f/cases/19972/Implementers-code-
> pane-undo-goes-too-far
> >
> > cheers -ben
>
>

Re: [Pharo-dev] stepping off the end of the debug stack

[Nicolai Hess]

2017-04-08 6:46 GMT+02:00 Ben Coman :

>
>
> On Sat, Apr 8, 2017 at 12:32 PM, Ben Coman  wrote:
>
>>
>> I imagine a newcomer exploring the system could easily step off the end
>> of the debug stack like this...
>>
>> (1 printString)   "debugIt"
>> then StepOver six times where the image hangs at "Processor
>> terminateActive"
>>
>> This could have a strong impact against first impressions.
>> What would it take to guard against this?
>>
>> cheers -ben
>>
>
> As an immediate stop-gap I'm adding the following comment to
>  BlockClosure>>newProcess
>
> "IMPORTANT! Debug stepping this deep infrastructure may lock your Image"
> "If you are not sure what you are doing, close the debugger now."
>
> cheers -ben
>


+1

Re: [Pharo-dev] More Windows VM Crashing -_-

[Nicolai Hess]

2017-03-22 10:31 GMT+01:00 Peter Uhnak :

> Hi,
>
> Originally I thought my VM is crashing because of FT, so I applied some
> fix from FogBugz (that is now part of Pharo 6), but that didn't help.
>
> So I disabled FT in settings and changed fonts to non-FT ones; didn't help.
> So I completely removed FT2Plugin.dll (now settings just states that FT
> fonts are not available), but that didn't help either.
>
> And obviously there is no crash.dmp whatsoever (this is latest Windows VM).
>
> This crash is extremely frustrating because the crash happens _during
> saving_, which means I am losing code all the time and have to constantly
> recover them, which really makes my blood boil.
>
> Without crash dump I don't even know where and how to start investigating.
> Windows kindly opens Visual Studio when Pharo crashes, but all it shows to
> me is assembly, which is not very useful to me. I can somewhat orient
> myself in the C code of the VM (as I've alredy fixed some other issues in
> the VM), but here I am lost.
>
> 
> 00407D7F  ret
> 00407D80  mov eax,dword ptr ds:[00596E44h]
> 00407D85  testal,3
> 00407D87  jne 00407DB2
> 00407D89  mov ecx,dword ptr ds:[596E08h]
> 00407D8F  lea edx,[ecx-1]
> 00407D92  cmp eax,edx
> 00407D94  jb  00407DB2
> 00407D96  cmp dword ptr ds:[596E10h],eax
> 00407D9C  jb  00407DB2
> 00407D9E  mov ecx,dword ptr ds:[5B89D0h]
> 00407DA4  cmp dword ptr [eax-4],ecx
> 00407DA7  jb  00407DB2
> 00407DA9  mov eax,dword ptr ds:[00596E28h]
> ---> 00407DAE  movzx   eax,byte ptr [eax]
> 00407DB1  ret
>
> eax = 
> ecx = 0470
> 
>
> So my question I guess is:
> How can we fix this? How can I help fix this? Because I've lost countless
> days of time and energy on this f***ing problem...
>
> Peter
>
>
Maybe it would help if other people try to reproduce this error.
Can you share the image/code you are using ?

Do you have a mingw build environment ? Sometimes it helps to start the vm
with gdb, and if an exception occurs that does not write a crash.dmp, if
you are lucky, gdb will show some additional information.


(for me, the latest windows vm *sometimes* does create a crash.dmp).

Re: [Pharo-dev] Pharo 6 vm crashed when pasting a big file

[Nicolai Hess]

2017-03-22 11:04 GMT+01:00 :

> Hi,
>
> The pharo 6 vm crashed when I pasted a long text file in the body of a
> method.
> Surprisingly, the vm did not crashed when I pasted a file of approximately
> the same size but only containing a single string ('adafcawa' copy-pasted
> on 8000 lines).
>
> The crash occured after I:
> - Opened a fresh image (60450)
> - Created a package, with a single class, with a single method
> - Tried to paste the content of the attached file into the methods body
> (the vm froze for 20-30 seconds then crashed)
>
> Ubuntu 16.04 LTS
> 64 bits
> vm obtained from http://get.pharo.org/ (the '60+vm' package)
> image 60450
>
> Thomas
>


Hi,
this is somehow related to syntax highlighting and that the parser for
syntax highlighting stops due to a syntax error.
You can disable syntax highlighting.
SHPreferences enabled:false.

And if you just paste this code as a string

foo
^ 'YOUR_FILE_CONTENTS'

the syntax error occurs from line 35 of your file contents:

 Other Elements. All syntactic structures that don't fall

this lines contains a quote and the parser tries to parse the remaining
part as code.

What I don't understand, sometimes it is working (code pane just shows the
code with all after the text
"don't" highlighted red, indicating a syntax error). And sometimes it does
not work and  the vm just consumes a
ridiculous amount of memory ~ 1GB.

Re: [Pharo-dev] PharoSpur32Vm

[Nicolai Hess]

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

>
>
> 2017-03-17 23:40 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com>:
>
>>
>>
>> 2017-03-17 23:32 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:
>>
>>>
>>>
>>> 2017-03-16 21:51 GMT+01:00 Nicolas Cellier <
>>> nicolas.cellier.aka.n...@gmail.com>:
>>>
>>>>
>>>>
>>>> 2017-03-15 18:14 GMT+01:00 Nicolas Cellier <
>>>> nicolas.cellier.aka.n...@gmail.com>:
>>>>
>>>>>
>>>>>
>>>>> 2017-03-15 15:03 GMT+01:00 Esteban Lorenzano <esteba...@gmail.com>:
>>>>>
>>>>>> sorry for coming late to this thread… hard week :)
>>>>>> why we are trying to compile with cygwin?
>>>>>> is there a problem with the mingw distro?
>>>>>>
>>>>>> I didn’t have the time to update the README, sadly. But well…
>>>>>> following appveyor configuration should give you all you need to 
>>>>>> reproduce
>>>>>> the build (that’s what I did last time I built an environment).
>>>>>>
>>>>>> Esteban
>>>>>>
>>>>>>
>>>>>> Hi Esteban,
>>>>> How did you solve the directx problem?
>>>>>
>>>>>
>>>>
>>>> Hurrah, I succeeded in compiling Win32 Pharo VM from cygwin by using
>>>> cross-compiler i686-w64-mingw32
>>>> (cygwin64 here but it could be cygwin32).
>>>>
>>>> This is good news, because it means that:
>>>> - we don't have to rely anymore on non-redistributable legacy directx
>>>> SDK
>>>> - we can compile with clang if we want too (well, for all the 3rd party
>>>> dependencies, that's a bit more work)
>>>> - it opens the door to win64 version
>>>>
>>>> Some details remain: I have to pick the right libgcc and libwindpthread
>>>> as weel as iconv.dll and copy them to the pharo build directory to satisfy
>>>> the SDL2 dependencies.
>>>> Maybe there's a better option for compiling SDL2 with more static
>>>> stuff? -static-libgcc or something...
>>>>
>>>> cairo required another dirty hack, not the one of Igor which must be
>>>> eliminated for cygwin compilation, but one for working around the files
>>>> that are not truncated when overwritten...
>>>> I wonder where this bug comes from? make? cygwin itself? VirtualBox
>>>> (unlikely)?
>>>>
>>>
>>> what hack from Igor ? I thought the pharo build just downloads a tar.gz
>>> archive from cairo and starts the configure/build ?
>>>
>>>
>>
>> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/f7d
>> 3c98eaa001d2d07c1f2b75cad00fa16f86a73
>>
>>
> and https://lists.cairographics.org/archives/cairo/2012-
> October/023675.html
>


Ok :)

Re: [Pharo-dev] PharoSpur32Vm

[Nicolai Hess]

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

>
>
> 2017-03-15 18:14 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com>:
>
>>
>>
>> 2017-03-15 15:03 GMT+01:00 Esteban Lorenzano <esteba...@gmail.com>:
>>
>>> sorry for coming late to this thread… hard week :)
>>> why we are trying to compile with cygwin?
>>> is there a problem with the mingw distro?
>>>
>>> I didn’t have the time to update the README, sadly. But well… following
>>> appveyor configuration should give you all you need to reproduce the build
>>> (that’s what I did last time I built an environment).
>>>
>>> Esteban
>>>
>>>
>>> Hi Esteban,
>> How did you solve the directx problem?
>>
>>
>
> Hurrah, I succeeded in compiling Win32 Pharo VM from cygwin by using
> cross-compiler i686-w64-mingw32
> (cygwin64 here but it could be cygwin32).
>
> This is good news, because it means that:
> - we don't have to rely anymore on non-redistributable legacy directx SDK
> - we can compile with clang if we want too (well, for all the 3rd party
> dependencies, that's a bit more work)
> - it opens the door to win64 version
>
> Some details remain: I have to pick the right libgcc and libwindpthread as
> weel as iconv.dll and copy them to the pharo build directory to satisfy the
> SDL2 dependencies.
> Maybe there's a better option for compiling SDL2 with more static stuff?
> -static-libgcc or something...
>
> cairo required another dirty hack, not the one of Igor which must be
> eliminated for cygwin compilation, but one for working around the files
> that are not truncated when overwritten...
> I wonder where this bug comes from? make? cygwin itself? VirtualBox
> (unlikely)?
>

what hack from Igor ? I thought the pharo build just downloads a tar.gz
archive from cairo and starts the configure/build ?


>
> If I find the energy to rebase -i and clean a bit my non linear attempts
> (squash/reorder/...) then I'll push the branch on opensmalltalk-vm and see
> how appveyor like it.
>
>
>
>
>> On 15 Mar 2017, at 10:11, Nicolai Hess <nicolaih...@gmail.com> wrote:
>>>
>>>
>>>
>>> 2017-03-15 9:22 GMT+01:00 philippe.b...@highoctane.be <
>>> philippe.b...@gmail.com>:
>>>
>>>> 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.
>>>>
>>>
>>> Ah good, thank you.
>>>
>>>
>>>
>>>>
>>>> HTH
>>>>
>>>> Phil
>>>>
>>>> Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaih...@gmail.com> a écrit :
>>>>
>>>>>
>>>>>
>>>>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier >>>> i...@gmail.com>:
>>>>>
>>>>>>
>>>>>>
>>>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier >>>>> i...@gmail.com>:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2017-03-11 10:01 GMT+01:00 Nicolas Cellier >>>>>>> i...@gmail.com>:
>>>>>>>>
>>>>>>>>> Hi Nicolai,
>>>>>>

Re: [Pharo-dev] PharoSpur32Vm

[Nicolai Hess]

2017-03-15 9:22 GMT+01:00 philippe.b...@highoctane.be <
philippe.b...@gmail.com>:

> 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.
>

Ah good, thank you.



>
> HTH
>
> Phil
>
> Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaih...@gmail.com> a écrit :
>
>>
>>
>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai
>> l.com>:
>>
>>>
>>>
>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai
>>> l.com>:
>>>
>>>>
>>>>
>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:
>>>>
>>>>>
>>>>>
>>>>> 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..  -

Re: [Pharo-dev] PharoSpur32Vm

[Nicolai Hess]

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

>
>
> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com>:
>
>>
>>
>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:
>>
>>>
>>>
>>> 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/
> opensmalltalk-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/
> opensmalltalk-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]
> cairo-test-constructors.c:1119:5: attention : la définition de données
> n'a pas de type ni de classe de stockage
>  _register_ft_show_glyphs_table ();
>  ^
>
> And the file looks like it has obviously been overwritten, but not
> truncated !!!
>
> ...
> extern void _register_multi_page (void);
> extern void _register_fallback_resolution (void);
>
> void
> _cairo_test_runner_register_tests (void)
> {
> _register_a1_bug ();
> _register_a1_clip_paint

Re: [Pharo-dev] Pharo6 supported syntax regression

[Nicolai Hess]

2017-03-13 16:47 GMT+01:00 Peter Uhnak :

> Hi,
>
> apparently in Pharo 6 pragma attributes can no longer be symbols without
> hash?
>
> In Pharo5 I could do
>
> method
> 
>
> and it would compile it as symbol
>
> In Pharo6 this is syntax error.
>
> I am not asking for resolution either direction (although I guess
> #Something should be canonical), it is just odd to me that the syntax would
> change (and maybe some code where people like me forgot to add hash sign
> will break).
>

Actually, I think the behavior in Pharo5 was broken, it should not compile,
and we fixed it for Pharo 6.



>
> Peter
>
>

Re: [Pharo-dev] PharoSpur32Vm

[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-
> project/pharo-vm/blob/master/.appveyor.yml and follow the scripts there.
>

Ok, thank you.


>
> I hope that Esteban will find time to resolve all these problems and have
> pharo brand back on opensmalltalk-vm. I guess that any form of help is
> welcome.
>
> Nicolas
>
>
> 2017-03-11 8:33 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:
>
>> I still have problems building a vm on windows.
>> can you give me some hints how to start ?
>> I cloned the recent pharo-vm project,
>> in opensmalltalk-vm\build.win32x86\pharo.cog.spur\
>> run
>> mvm
>>
>> But I got a couple of problems (mingw-32 compiler commands not found, I
>> had to adjust the include path for finding directx header, missing variable
>> replacement for git-versions).
>> So I may miss some important steps.
>> Is there a repository where I can clone the mingw environment used to
>> build the win32-pharo-vm, the environment used on the build-server ?
>>
>> Thanks
>> Nicolai
>>
>> 2017-02-04 1:50 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:
>>
>>>
>>>
>>> 2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:
>>>
>>>>
>>>>
>>>> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <esteba...@gmail.com>:
>>>>
>>>>>
>>>>> On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaih...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> 2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clem...@gmail.com>:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I believe they're built from* https://github.com/OpenSmalltalk/vm
>>>>>> <https://github.com/OpenSmalltalk/vm>* using travis and appveyor. On
>>>>>> the gitbhub readme there are relevant links. All built artifacts are also
>>>>>> kept on bintray for history.
>>>>>>
>>>>>>
>>>>>>
>>>>> Thank you!
>>>>>
>>>>>
>>>>> no, they aren’t :)
>>>>> instead, they are built here: https://github.com/pharo
>>>>> -project/pharo-vm
>>>>>
>>>>> (README still not updated)
>>>>>
>>>>
>>>> what did changed ? I am not able to build the vm on windows anymore
>>>> (something wrong with generating the generator.image, I'll now reset my
>>>> local pharo-vm build directory and see if it works afterwards).
>>>>
>>>
>>> see attached the stderr log :
>>>
>>> 'Errors in script loaded from u:\github\pharo-vm\scripts\LoadVMMaker.st'
>>> [31mMessageNotUnderstood: receiver of "default:" is nil
>>> [0mUndefinedObject(Object)>>doesNotUnderstand: #default:
>>> BaseSoundSystem class>>initialize
>>> MCMethodDefinition>>postloadOver:
>>>
>>> 
>>>
>>>
>>>> Are we still working with branch spur-64, or are we back on master ?
>>>>
>>>>
>>>>
>>>>>
>>>>> Esteban
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess <nicolaih...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Where are the latest Pharo-spur-vms (32bit) are built?
>>>>>>> I don't see them on the build server, only the buildresults at
>>>>>>> http://files.pharo.org/vm/pharo-spur32/linux/
>>>>>>>
>>>>>>> The latest builds on the buildserver are from the last year only.
>>>>>>>
>>>>>>> nicolai
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [Pharo-dev] PharoSpur32Vm

[Nicolai Hess]

I still have problems building a vm on windows.
can you give me some hints how to start ?
I cloned the recent pharo-vm project,
in opensmalltalk-vm\build.win32x86\pharo.cog.spur\
run
mvm

But I got a couple of problems (mingw-32 compiler commands not found, I had
to adjust the include path for finding directx header, missing variable
replacement for git-versions).
So I may miss some important steps.
Is there a repository where I can clone the mingw environment used to build
the win32-pharo-vm, the environment used on the build-server ?

Thanks
Nicolai

2017-02-04 1:50 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:

>
>
> 2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:
>
>>
>>
>> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <esteba...@gmail.com>:
>>
>>>
>>> On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaih...@gmail.com> wrote:
>>>
>>>
>>>
>>> 2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clem...@gmail.com>:
>>>
>>>> Hi,
>>>>
>>>> I believe they're built from* https://github.com/OpenSmalltalk/vm
>>>> <https://github.com/OpenSmalltalk/vm>* using travis and appveyor. On
>>>> the gitbhub readme there are relevant links. All built artifacts are also
>>>> kept on bintray for history.
>>>>
>>>>
>>>>
>>> Thank you!
>>>
>>>
>>> no, they aren’t :)
>>> instead, they are built here: https://github.com/pharo-project/pharo-vm
>>>
>>> (README still not updated)
>>>
>>
>> what did changed ? I am not able to build the vm on windows anymore
>> (something wrong with generating the generator.image, I'll now reset my
>> local pharo-vm build directory and see if it works afterwards).
>>
>
> see attached the stderr log :
>
> 'Errors in script loaded from u:\github\pharo-vm\scripts\LoadVMMaker.st'
> [31mMessageNotUnderstood: receiver of "default:" is nil
> [0mUndefinedObject(Object)>>doesNotUnderstand: #default:
> BaseSoundSystem class>>initialize
> MCMethodDefinition>>postloadOver:
>
> 
>
>
>> Are we still working with branch spur-64, or are we back on master ?
>>
>>
>>
>>>
>>> Esteban
>>>
>>>
>>>
>>>>
>>>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess <nicolaih...@gmail.com>
>>>> wrote:
>>>>
>>>>> Where are the latest Pharo-spur-vms (32bit) are built?
>>>>> I don't see them on the build server, only the buildresults at
>>>>> http://files.pharo.org/vm/pharo-spur32/linux/
>>>>>
>>>>> The latest builds on the buildserver are from the last year only.
>>>>>
>>>>> nicolai
>>>>>
>>>>
>>>>
>>>
>>>
>>
>

Re: [Pharo-dev] Catalog projects in Spotter

[Nicolai Hess]

2017-03-10 20:18 GMT+01:00 stepharong :

> Torsten
>
> Why are you full of bad energy?
> Having a setting is perfectly ok. Why all this bad energy.
>

The problem is not having a setting, the problem is to have *two* distinct
settings for the same thing.


>
> Do you think that this is nice to hear that I push solution for fucking
> african idiots?
> I spent so much time writing and producing solutions for newbies.
> I just spent three months fixing the Pharo by example book and THIS IS NOT
> MY JOB.
> Do you think that writing a full mooc that we can use to promote Pharo all
> over the world
> is not important? I was not in the mood to write it. For my CV a mooc is
> nothing.
> Zero impact.
> You see when people evaluate my CV I got feedback like
> "stephane is a brillant researcher but he is focusing too much on
> poor languages."
> And many other things.
> So now you can be aggressive and pissed. I decided long time ago that I do
> Pharo for positive
> energy. Now if you do not like what I'm doing I cannot do much.
>
> Stef
>
>
>
>
> Uko wrote:
>>
>>> If there is a rule not to duplicate preferences, why is catalog not
>>> following it?
>>>
>>
>> Because at the time when I implemented it for catalog there was no other
>> setting.
>>
>> The enabling/disabling for all GT extension was introduced later. Also
>> the confusing
>> default was introduced later (with the more hidden spotter extension
>> disabled and
>> leaving the Catalog setting enabled) leading to this whole mess.
>>
>> To be honest I dont care or respond anymore on the whole issue because as
>> we now know from
>> the long discussion the only outcome is that:
>>
>> 
>>   - most of us should be knowledgable enough to know that two settings
>> exist
>>   - most of us should become experts in fixing deficencies with startup
>> scripts
>>   - most of us should accept that we have to hide features as deep as
>> possible in the settings tree
>>   - most of us should accept that we have to make it as complicated as
>> possible to load catalog projects
>>   - most of us should accept that we can display and access anything in
>> spotter except catalog projects
>>   - most of us should accept that Pharo videos get broken and never match
>> reality
>>   - most of us should continue to "rest in their comfort zone"
>>   - most of us should continue to be "an egoist instead of being an adult"
>>   - most of us should be allowed to speak up only when they presented
>> Pharo at a university
>>   - most of us should start working with slow networks
>> 
>>
>> Fixing it by removing Spotter and Catalog completely from Pharo would
>> possibly be the
>> best solution. Anyone up for a slice?
>>
>> Bye
>> T.
>>
>>
>
> --
> Using Opera's mail client: http://www.opera.com/mail/
>
>

Re: [Pharo-dev] [Pharo-users] What is the craziest bug you ever face

[Nicolai Hess]

2017-03-09 12:36 GMT+01:00 Stephane Ducasse :

> Hi guys
>
> During the DSU workshop we were brainstorming about what are the most
> difficult bugs we faced and what are the conceptual tools that would have
> helped you.
>
> Stef
>

https://pharo.fogbugz.com/f/cases/14332/use-ast-not-parseTree-so-we-benefit-from-the-ASTCache#BugEvent.113561
Running a RBLintRule modified the (cached) AST of this methods code. So,
even if the compiled method did not changed, and the "real" source code did
not changed, you actually see
the source code from the modified AST.

There are a couple of things which went wrong resp. make this bug difficult:
1. A LintRule that just should *check* the code, actually created a
transformation somewhere behind the scene (Ok, it is a
RBTransformationRule, and originally used for code refactoring as well)
2. As long as we *analyze* code, the real code (string/ast/source) should
be considered immutable
3. the modified AST was cached
4. what-you-see-is-not-what-you-get. We are (or I am) used to consider the
system browser a tool for view and edit methods source code. If the code we
see isn't actually the methods source, but another representation of some
kind of (cached) model (formatted AST-node-source code), it would be good
to have some way to indicate this (switch between "raw"-code / model-code /
ast-node-code).

Re: [Pharo-dev] Pharo 6 cannot parallel trace through same method

[Nicolai Hess]

2017-02-08 16:37 GMT+01:00 Ben Coman :

>
> This has bugged me a few times recently, so I've produced a demo.
> Define...
>
>   Object subclass: #AA
> instanceVariableNames: ''
> classVariableNames: ''
> package: ''
>
>   AA>>test
> self haltOnce.
> self inform: 'I got here'.
>
> then in playground evaluate
>   Halt resetOnce. "i.e. World > Debugging > Enable all break/inspect once."
>   AA new test.
>
> and as expected you get a debugger window.
> Now once again without closing the debugger ...
>   Halt resetOnce.
>   AA new test.
>
> and I'd expect another debugger, but instead I'm informed 'I got here'.
> Its extremely useful sometimes to parallel trace through code comparing
> two cases,
> and the current behaviour prevents that. .
>
> The Pharo 5 equivalent works as expected...
>   Halt enableHaltOnce.
>   AA new test.
>
> I'm not sure where to hang it, but the following test
> differentiates between Pharo 5 & 6. (you can also run it from the
> playground.)
>
>  testParallelTrace
> |completed p1 ds1 p2 ds2|
> completed := 0.
> Halt resetOnce. "enableHaltOnce"
> p1 := [ self haltOnce. completed := completed + 1 ] newProcess.
> ds1 := DebugSession named: 'Trace1' on: p1 startedAt: p1
> suspendedContext.
> ds1 resume.
> Halt resetOnce. "enableHaltOnce"
> p2 := [ self haltOnce. completed := completed + 1 ] newProcess.
> ds2 := DebugSession named: 'Trace2' on: p2 startedAt: p2
> suspendedContext.
> ds2 resume.
> self assert: (completed = 0)
>
> I've opened
> https://pharo.fogbugz.com/f/cases/19677/Cannot-parallel-
> trace-through-same-method
>
> cheers -ben
>
>
I think this is a result of the change how haltOnce are now implemented
with metalinks.



>
>
> P.S. I'm not sure if enabling the global haltOnce might cause issues.
> It would be useful to be able to set it only for the DebugSession.
>

Re: [Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)

[Nicolai Hess]

2017-02-04 13:40 GMT+01:00 Sven Van Caekenberghe <s...@stfx.eu>:

>
> > On 4 Feb 2017, at 13:01, Nicolai Hess <nicolaih...@gmail.com> wrote:
> >
> >
> >
> > 2017-02-04 12:49 GMT+01:00 Sven Van Caekenberghe <s...@stfx.eu>:
> > Hi Nicolai,
> >
> > The FileSystem API is a bit inconsistent, yes.
> >
> > This is how you can use it:
> >
> > (FileLocator temp / 'foo.txt') writeStreamDo: [ :out |
> >   out binary.
> >   (ZnCharacterWriteStream on: out encoding: #utf8) << 'élève' ].
> >
> > (FileLocator temp / 'foo.txt') readStreamDo: [ :in |
> >   in binary.
> >   ZnCharacterReadStream on: in encoding: #utf8) upToEnd ].
> >
> > (FileLocator temp / 'foo.txt') binaryReadStreamDo: [ :in |
> >   (ZnCharacterReadStream on: in encoding: #utf8) upToEnd ].
> >
> > There is no #binaryWriteStreamDo:
> >
> > The API around File is more correct, IMHO.
> >
> > Does this help ?
> >
> > Yes, thanks for the fast response.
> >
> > What exactly is your question ?
> >
> > I am looking at the issues with FileList, there are some parts that
> don't work anymore (see FileList>>#contents, it calls some unimplemted
> methods), and it uses TextConverter and somoe parts of the older File api.
> > It looks like most other (newer) parts are using ZnCharacterReadstream
> for encoding, but I couldn't find a way to use it together with
> FileReferences (most parts of the FileList already operate with the newer
> FileSystem API.
>
> OK.
>
> From my standpoint and understanding, I would always use binary streams
> with explicit Zn converters, this combination is much easier to understand
> and better implemented with more features.
>
> If you encounter any problem or have any questions, I will gladly try to
> help you.
>

:-)
Is there a way to list all supported encodings, similar to TextConverter
class >> #allEncodingNames ?
I only found
ZnSimplifiedByteEncoder class >> #knownEncodingIdentifiers
and
ZnByteEncoder class >> #knownEncodingIdentifiers
and nothing for all supported utf-8/16 ... encodings.

nicolai


>
> > Sven
> >
> > > On 4 Feb 2017, at 12:09, Nicolai Hess <nicolaih...@gmail.com> wrote:
> > >
> > > Hi
> > > How can I specify the character encoding when opening a readStream on
> a FileRerefence.
> > >
> > > I found this, that works:
> > >
> > > | readStream fileContent |
> > > readStream := (File named: aFileName) openForRead.
> > > fileContent := ZnCharacterReadStream on: readStream encoding: encoding.
> > >  fileContent upToEnd asString.
> > >
> > > But if I try to do the same with a readStream from a FileReference
> > >
> > > | readStream fileContent |
> > > readStream := aFileName asFileReference readStream.
> > > fileContent := ZnCharacterReadStream on: readStream encoding: encoding.
> > >  fileContent upToEnd asString.
> > >
> > > I get an error SmallInteger DNU #asciiValue,
> > >
> > > this is because, in the first method, we create a binary filestream,
> and if we
> > > use readStream from a FileReference, the stream is a
> MultibyteFileStream.
> > >
> > > How can I us ZnEncoder for a readstream from a FileReference?
> > >
> > > (and is it on purpose that both readStream method
> (openForRead/readStream)
> > > return different kinds of binary streams?)
> > >
> > >
> > > nicolai
>
>
>

[Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)

[Nicolai Hess]

Hi
How can I specify the character encoding when opening a readStream on a
FileRerefence.

I found this, that works:

| readStream fileContent |
readStream := (File named: aFileName) openForRead.
fileContent := ZnCharacterReadStream on: readStream encoding: encoding.
 fileContent upToEnd asString.

But if I try to do the same with a readStream from a FileReference

| readStream fileContent |
readStream := aFileName asFileReference readStream.
fileContent := ZnCharacterReadStream on: readStream encoding: encoding.
 fileContent upToEnd asString.

I get an error SmallInteger DNU #asciiValue,

this is because, in the first method, we create a binary filestream, and if
we
use readStream from a FileReference, the stream is a MultibyteFileStream.

How can I us ZnEncoder for a readstream from a FileReference?

(and is it on purpose that both readStream method (openForRead/readStream)
return different kinds of binary streams?)


nicolai

Re: [Pharo-dev] PharoSpur32Vm

[Nicolai Hess]

2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:

>
>
> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <esteba...@gmail.com>:
>
>>
>> On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaih...@gmail.com> wrote:
>>
>>
>>
>> 2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clem...@gmail.com>:
>>
>>> Hi,
>>>
>>> I believe they're built from* https://github.com/OpenSmalltalk/vm
>>> <https://github.com/OpenSmalltalk/vm>* using travis and appveyor. On
>>> the gitbhub readme there are relevant links. All built artifacts are also
>>> kept on bintray for history.
>>>
>>>
>>>
>> Thank you!
>>
>>
>> no, they aren’t :)
>> instead, they are built here: https://github.com/pharo-project/pharo-vm
>>
>> (README still not updated)
>>
>
> what did changed ? I am not able to build the vm on windows anymore
> (something wrong with generating the generator.image, I'll now reset my
> local pharo-vm build directory and see if it works afterwards).
>

see attached the stderr log :

'Errors in script loaded from u:\github\pharo-vm\scripts\LoadVMMaker.st'
[31mMessageNotUnderstood: receiver of "default:" is nil
[0mUndefinedObject(Object)>>doesNotUnderstand: #default:
BaseSoundSystem class>>initialize
MCMethodDefinition>>postloadOver:




> Are we still working with branch spur-64, or are we back on master ?
>
>
>
>>
>> Esteban
>>
>>
>>
>>>
>>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess <nicolaih...@gmail.com>
>>> wrote:
>>>
>>>> Where are the latest Pharo-spur-vms (32bit) are built?
>>>> I don't see them on the build server, only the buildresults at
>>>> http://files.pharo.org/vm/pharo-spur32/linux/
>>>>
>>>> The latest builds on the buildserver are from the last year only.
>>>>
>>>> nicolai
>>>>
>>>
>>>
>>
>>
>


stderr
Description: Binary data

Re: [Pharo-dev] PharoSpur32Vm

[Nicolai Hess]

2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <esteba...@gmail.com>:

>
> On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaih...@gmail.com> wrote:
>
>
>
> 2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clem...@gmail.com>:
>
>> Hi,
>>
>> I believe they're built from* https://github.com/OpenSmalltalk/vm
>> <https://github.com/OpenSmalltalk/vm>* using travis and appveyor. On the
>> gitbhub readme there are relevant links. All built artifacts are also kept
>> on bintray for history.
>>
>>
>>
> Thank you!
>
>
> no, they aren’t :)
> instead, they are built here: https://github.com/pharo-project/pharo-vm
>
> (README still not updated)
>

what did changed ? I am not able to build the vm on windows anymore
(something wrong with generating the generator.image, I'll now reset my
local pharo-vm build directory and see if it works afterwards).
Are we still working with branch spur-64, or are we back on master ?



>
> Esteban
>
>
>
>>
>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess <nicolaih...@gmail.com>
>> wrote:
>>
>>> Where are the latest Pharo-spur-vms (32bit) are built?
>>> I don't see them on the build server, only the buildresults at
>>> http://files.pharo.org/vm/pharo-spur32/linux/
>>>
>>> The latest builds on the buildserver are from the last year only.
>>>
>>> nicolai
>>>
>>
>>
>
>

Re: [Pharo-dev] PharoLauncher create image / default image name

[Nicolai Hess]

Am 03.02.2017 12:35 nachm. schrieb "Peter Uhnak" <i.uh...@gmail.com>:

I was also looking at this, but couldn't figure out how to change it back,

Do you know in what specific commit this happened?

PharoLauncher-Core-ChristopheDemarey.100



(I prefer the old naming, since it included context and I knew whether the
image was Pharo or Moose).

Thanks,
Peter

On Wed, Feb 01, 2017 at 08:23:33PM +0100, Cyril Ferlicot D. wrote:
> Le 01/02/2017 à 20:18, Nicolai Hess a écrit :
> > I started to use a more recent version of pharo launcher, and somehow it
> > changed how it creates the default image name when creating a new image.
> > For example, select an entry from "Pharo 6.0 (beta)" template, the old
> > behavior sets the default name to
> > Pharo 6.0 (beta) - 60353
> > but now, the template name is omitted, it only sets
> > 60535
> >
> > was this change on purpose ? I can not find an issue about this on
> > https://github.com/pharo-project/pharo-launcher/issues
> >
> > (I actually don't care much about which format to use, it is just that
> > all my images I used from the prior version, and the new one now appear
> > on different positions in the images list)
> >
> > nicolai
>
> Hi,
>
> This change was made by Christophe I think and was in purpose.
>
> Template name before: Name of the "location" (ex: Common Tools, Pharo
> Contribution Jenkins, Pharo 6.0…) - Name of the build
>
> Now: Name of the build
>
> --
> Cyril Ferlicot
>
> http://www.synectique.eu
>
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
>

[Pharo-dev] PharoLauncher create image / default image name

[Nicolai Hess]

I started to use a more recent version of pharo launcher, and somehow it
changed how it creates the default image name when creating a new image.
For example, select an entry from "Pharo 6.0 (beta)" template, the old
behavior sets the default name to
Pharo 6.0 (beta) - 60353
but now, the template name is omitted, it only sets
60535

was this change on purpose ? I can not find an issue about this on
https://github.com/pharo-project/pharo-launcher/issues

(I actually don't care much about which format to use, it is just that all
my images I used from the prior version, and the new one now appear on
different positions in the images list)

nicolai

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

[Nicolai Hess]

2017-01-30 15:23 GMT+01:00 Pavel Krivanek <pavel.kriva...@gmail.com>:

> 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 <nicolaih...@gmail.com>:
>
>> For example:
>> 19457
>> <https://pharo.fogbugz.com/f/cases/19457/Scrolling-Versionner-configuration-list-is-very-slow>
>> Scrolling Versionner configuration list is very slow
>> 18778
>> <https://pharo.fogbugz.com/f/cases/18778/FileList-View-as-does-not-work>
>> FileList "View as" does not work
>> 19221
>> <https://pharo.fogbugz.com/f/cases/19221/Rub-Find-And-Replace-can-not-search-for>
>> 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
>>
>
>

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

[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] Any idea for a cool name for the remote tool suite?

[Nicolai Hess]

PharoRemoteToolSet
 :)

Re: [Pharo-dev] AST node replacement API

[Nicolai Hess]

2017-01-23 14:48 GMT+01:00 Yuriy Tymchuk :

> Hi everyone,
>
> does anyone have a better knowledge about replacing nodes in AST? Because
> what I saw is that there are methods like replaceSourceWith: that can be
> sent to an AST node with another AST node as a parameter. But this is not
> enough to get a new source code. Because when you ask the AST for newSource
> it generates a new source by taking replacements into account, parses the
> new source, compares it with itself and in case the new parse tree is equal
> it returns the new source. So it’s not enough to just use
> replaceSourceWith: but you also have to replace the current node with a new
> one it AST.
>
> Now the question is: am I doing something wrong, or we have strange API
> because we need to replace both source and node, replacing only one of them
> does not work…
>

The API is strange : )
The nodeMapping and replacements are used by the tree rewriter. And the way
the treerewriter works, it does not rewrite a AST-Tree but generates a new
method by compiling the returned
value, and it works on the returned value, the new/reformatted source text,
not on a changed AST-Tree.
>From the rewriter point of view (and some other parts of RB), the AST is
more like a immutable structure. Only since when we started to use the
RB-AST for the compiler, we started
to use the AST for other purposes

(remember when we got into trouble, because some lint rules from critic
browser were modifying the AST and we used that modified source as the
method source, although the actual
method source didn't changed )


>
> Uko
>

Re: [Pharo-dev] PharoSpur32Vm

[Nicolai Hess]

2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clem...@gmail.com>:

> Hi,
>
> I believe they're built from* https://github.com/OpenSmalltalk/vm
> <https://github.com/OpenSmalltalk/vm>* using travis and appveyor. On the
> gitbhub readme there are relevant links. All built artifacts are also kept
> on bintray for history.
>
>
>
Thank you!


>
> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess <nicolaih...@gmail.com>
> wrote:
>
>> Where are the latest Pharo-spur-vms (32bit) are built?
>> I don't see them on the build server, only the buildresults at
>> http://files.pharo.org/vm/pharo-spur32/linux/
>>
>> The latest builds on the buildserver are from the last year only.
>>
>> nicolai
>>
>
>

[Pharo-dev] PharoSpur32Vm

[Nicolai Hess]

Where are the latest Pharo-spur-vms (32bit) are built?
I don't see them on the build server, only the buildresults at
http://files.pharo.org/vm/pharo-spur32/linux/

The latest builds on the buildserver are from the last year only.

nicolai

Re: [Pharo-dev] looking for classbuilder API

[Nicolai Hess]

maybe :

newClass setFormat: self classLayout format.


2017-01-15 9:40 GMT+01:00 stepharong :

> HI
>
> I need to migrate
>
> pvtNewSubclass
>
> | newClass |
> newClass := Behavior new.
> newClass superclass: self.
> newClass setFormat: (ClassBuilder new computeFormat: #normal
> instSize: 0 forSuper: self ccIndex: 0).
> ^newClass
>
> and I'm looking at how to express (ClassBuilder new computeFormat: #normal
> instSize: 0 forSuper: self ccIndex: 0).  in Pharo 60.
>
> Stef
>
>

Re: [Pharo-dev] problem with linux: missing

[Nicolai Hess]

The vm-display-X11
will be dynamically loaded, that is why you don't see the GL/X11 dependency
if you ldd on the vm (pharo-executable).

If you are on a 64Bit machine, you need to have 32Bit libraries for X11/GL
. And yes, it would be nice to have a headless vm not to depend on the
display library stuff.

2017-01-12 14:38 GMT+01:00 Nicolas Anquetil :

> more info on this,
>
> On my own computer, the dependencies are not the same:
>
> ---
>
> $ ldd pharo
> linux-gate.so.1 =>  (0xf7751000)
> libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf76ce000)
> libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf76c9000)
> libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf76ab000)
> libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf74f5000)
> /lib/ld-linux.so.2 (0x565c6000)
>
> ---
>
> Specifically, the two missing libraries (for hte others) are not requested
> on my computer.
>
> So why were they needed in the other cases? (I am using the same pharo5 as
> they do)
>
> nicolas
>
>
> On 12/01/2017 12:26, Nicolas Anquetil wrote:
>
>
> a fresh install of moose image failed to start on a number of Linux
> machines because of missing libraries
>
> the missing dependencies are libGL and libX11 that for some reasons were
> not installed (but it was a running linux with graphical interface).
>
> See below
>
> ---
>
> $ ldd vm-display-X11
> linux-gate.so.1 =>  (0xf7766000)
> libpthread.so.0 => /lib32/libpthread.so.0 (0xf76ff000)
> libGL.so.1 => not found
> libX11.so.6 => not found
> libc.so.6 => /lib32/libc.so.6 (0xf754b000)
> /lib/ld-linux.so.2 (0x5661f000)
>
> ---
>
> there should be a way to test that.
> Not too sure how. May be an installer in the form of a headless image
> using the system ldd (see above) command ?
>
>
> nicolas
>
> --
> Nicolas Anquetil -- MCF (HDR)
> Project-Team RMod
>
>
> --
> Nicolas Anquetil -- MCF (HDR)
> Project-Team RMod
>
>

Re: [Pharo-dev] No Projects at smalltalkhub

[Nicolai Hess]

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 <nicolaih...@gmail.com>:

>
>
> 2017-01-06 15:01 GMT+01:00 Esteban Lorenzano <esteba...@gmail.com>:
>
>> I restarted it and now I see 3 projects… is that correct?
>>
>
> YES
>
> Thanks.
>
>
>
>>
>> Esteban
>>
>> On 5 Jan 2017, at 23:16, Nicolai Hess <nicolaih...@gmail.com> wrote:
>>
>> All my projects at smalltalkhub.com are gone - again.
>> (http://smalltalkhub.com/#!/~NicolaiHess)
>>
>>
>>
>

Re: [Pharo-dev] No Projects at smalltalkhub

[Nicolai Hess]

2017-01-06 15:01 GMT+01:00 Esteban Lorenzano <esteba...@gmail.com>:

> I restarted it and now I see 3 projects… is that correct?
>

YES

Thanks.



>
> Esteban
>
> On 5 Jan 2017, at 23:16, Nicolai Hess <nicolaih...@gmail.com> wrote:
>
> All my projects at smalltalkhub.com are gone - again.
> (http://smalltalkhub.com/#!/~NicolaiHess)
>
>
>

[Pharo-dev] No Projects at smalltalkhub

[Nicolai Hess]

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

Re: [Pharo-dev] Do you think VersionBrowser is counterintuitive?

[Nicolai Hess]

Am 23.12.2016 2:28 nachm. schrieb "Denis Kudriashov" :

Hi.

I always catch myself that I am completely lost in method versions (and
feel pain :)).
There is no clue what at the left pane and what at the right pane.

Now I realize that VersionBrowser is trying to compare selected version
versus next version (according to list order).
So right pane shows selected version and left pane shows next one.
For me all of these is super non intuitive but maybe it is only my problem.
So here I want to ask about your experience. Do you feel same?

I would prefer if VersionBrowser will always compare selected version
versus current version in image with actual image version on the left and
selected version on the right.

What you think?

Best regards,
Denis



 But you can always select a version an choose
compare with current
from the context menu.

Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(

[Nicolai Hess]

Am 21.12.2016 8:10 vorm. schrieb "Alexandre Bergel" :

I had plenty of elements in my Roassal visualization, and on some point it
just crashed.
I have the impression that having many elements and / or animations (as in
the case of Johan Fabry) triggers the crash.



One problem, the one peter (partly) fixed, is n issue with bitblt, Cairo
(as a surface plugin) and garbage collection.
Bitblt my call the surface plugin to request some information about the
Form.
NB-based ffi for Cairo just called gen. asm code. But with UFFI, we now
callback to Smalltalk code, which may trigger a GC.
So every time bitblt, makes a call to the surface plugin (Cairo) and this
callback allocates a new ST-Object, the GC may run and moves(!)the objects,
to which bitblt still holds a reference.
Accessing this objects in bitblt, after the callback returns (may) result
in a segfault.
Depending on the concrete bltoperation, the object memory layout, the
size(!) of the initial Cairo surface.
With peters fix/hack, the code does not crash but it still may access and
operates on moved objects.
Pining the objects may help, but you need to know where in the (vm image)
code a form is used for drawing, and if it is a real form or external data
managed by the surface plugin.
And of course, when to "unpin" the object.

A saver way would be, to just disable any GC during the executing of the
callback, if it was called by a plugin (here:bitblt)



Alexandre


> On Dec 20, 2016, at 9:12 AM, Stephane Ducasse 
wrote:
>
> So what was your crash problem?
>
>
> On Tue, Dec 20, 2016 at 8:43 AM, Alexandre Bergel 
wrote:
> > so did it work?
> > Is there something that we should do?
>
> I had no problem, but as Henrik and Peter said, the problem is likely to
be more complex
>
> Alexandre
>
>
> >
> > On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel <
alexandre.ber...@me.com> wrote:
> > Okay, trying…
> >
> > Alexandre
> >
> >
> > > On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel 
wrote:
> > >
> > > According to crash.dmp TRMorph>drawOn: draws an image using
FormCanvas>>#image:at:sourceRect:rule:  at a coordinate represented by a
Float point.
> > > Try to round it to integer point.
> > >
> > > Cheers,
> > > Alex
> > >
> > > On 16 December 2016 at 16:34, Alexandre Bergel <
alexandre.ber...@me.com> wrote:
> > > Hi!
> > >
> > > Vincent and I are experiencing many crashes from GrafPort>copyBits.
It crashes every couple of minutes.
> > >
> > > I know that not much can be done so far. Stability is my biggest
concern with Pharo :-(
> > > I use the latest VM.
> > >
> > > Cheers,
> > > Alexandre
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > > Alexandre Bergel  http://www.bergel.eu
> > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> > >
> > >
> > >
> > >
> > > ___
> > > Moose-dev mailing list
> > > moose-...@list.inf.unibe.ch
> > > https://www.list.inf.unibe.ch/listinfo/moose-dev
> > >
> > >
> >
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
> >
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.