Re: [Pharo-dev] Anoying bug fond in Artefact running in Windows 10

[olivier auverlot]

Hi Casimiro,

Which version of Pharo do you use ? 6.1 ?

Olivier :)

2017-10-19 18:27 GMT+02:00 :

> When you insert a jpeg from a file, for some reason the file descriptor
> (stream) is kept open (at least in the Windows end of things). Then, if a
> second page is to be generated, the following error is shown:
>
> 'MessageNotUnderstood: receiver of "reset" is nil
>
> PDFJpegElement>>stream:
> JPEGReadWriter
> aJPEGReadWriter
> JPEGReadWriter(ImageReadWriter)>>on:
> nil
>
> Sample code:
>
> aPage := PDFPage new.
>
> imageStream := FileStream fileNamed: 'lsi-tec.jpg'.
>
> aPage
> add:
> ((PDFJpegElement fromStream: imageStream)
> from: 15 mm @ 20 mm;
> dimension: 40 mm @ 40 mm).
> imageStream close.
>
> Generated report is in annex
>
> The only way to recover is to close pharo, start it again. Then the file
> descriptor (stream) is released and it is possible to go on.
>
> Has anyone faced this problem?
> How to solve it?
>
> Best regards,
>
> Casimiro Barreto
>
>

Re: [Pharo-dev] Help for the mooc

[Ben Coman]

Was this fixed by replacing the redirect with an actual file?
I went to look at http://pharo.org/web/files/pharo.png
using Chrome "F12" Develop Tools to view the redirect,
and IIUC I directly got the PNG itself.  Just checking I'm interpreting
that correctly.

cheers -ben

On Wed, Oct 18, 2017 at 2:33 PM, Stephane Ducasse 
wrote:

> Tx!
> I should fix it but probably the videos are still using the old one.
>
> On Tue, Oct 17, 2017 at 10:36 PM, Sven Van Caekenberghe 
> wrote:
> >
> >
> >> On 17 Oct 2017, at 22:29, Stephane Ducasse 
> wrote:
> >>
> >> Hi
> >>
> >> students have a problem with the following in Pharo 50 (we could not
> upgrade)
> >>
> >> (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png') asMorph
> openInWindow
> >>
> >>
> >> ConnectionClosed : connection closed while waiting for data
> >>
> >> And well this is super annoying.
> >>
> >> Stef
> >
> > This is fixed in later versions. You can try the following:
> >
> > (ZnEasy getPng: 'http://pharo.org/files/pharo.png') asMorph
> openInWindow.
> >
> > The reason that last one works is that http://pharo.org/files/pharo.png
> is an http url that resolves directly, while http://pharo.org/web/files/
> pharo.png redirects to an https equivalent which can only be read with
> #serverName support. For this, you need not only a more recent version of
> Zinc, but also a newer VM with a more recent SSL plugin.
> >
> > Sven
>
>

Re: [Pharo-dev] UnifiedFFI Docs

[Todd Blanchard]

I have found the problem with VoidPointer3 generating accessors.

No idea how to contribute back a fix but this is what I've found.

FFITypeArrayType>>annonymousClassCreator
^ String streamContents: [ :stream |
stream 
nextPutAll: '(FFITypeArray ofType: ';
print: (self objectClass type isPointer ifTrue: [self 
externalTypeWithArity printString] ifFalse: ['#',self objectClass type class]);
nextPutAll: ' size: ';
print: self objectClass numberOfElements;
nextPutAll: ')' ]

Recalling that we are trying to come up with an accessor that can pull out a 
void*[3], this produces

'(FFITypeArray ofType: #FFIVoid size: 3)'

which produces an error as FFIVoid's size is undefined.  In general, this will 
be wrong for any pointer type and will probably get the size calculation wrong.

Doing a little digging I find that 

FFITypeArray>>ofType: aType size: aSize 

delegates resolution of aType to FFIExternalType>>resolveType:aType and this 
can take all kinds of different things including the native type name.

It would be better if this generated the native name for pointers.

(FFITypeArray ofType: 'void*' size: 3)

So I changed it to:

FFITypeArrayType>>annonymousClassCreator
^ String streamContents: [ :stream |
stream 
nextPutAll: '(FFITypeArray ofType: ';
print: (self objectClass type isPointer 
ifTrue: [self externalTypeWithArity 
printString] 
ifFalse: ['#',self objectClass type class]);
nextPutAll: ' size: ';
print: self objectClass numberOfElements;
nextPutAll: ')' ]

and this seems to work fine.

Onwards...

> On Oct 19, 2017, at 7:18 AM, Todd Blanchard  wrote:
> 
> That’s great - it’s been kind of magical but a couple things have changed 
> since you wrote it and some bugs have crept into ffi.
> 
> Right now I’m finding the generated accessor for the VoidPointer3 is actually 
> generating a void 3 accessor and that doesn’t work. I spent all day yesterday 
> tracking it to the accessor generating code.
> 
> Sent from the road
> 
> On Oct 18, 2017, at 22:29, Ben Coman  > wrote:
> 
>> 
>> 
>> On Thu, Oct 19, 2017 at 1:05 AM, Todd Blanchard > > wrote:
>> I'm working through Ben's great blog post about playing with libclang and I 
>> am puzzled by something.
>> 
>> Thx Todd. Knowing someone is looking at it encourages me to expand it.  
>> I'm interested in looking at your specific questions, but it might not be 
>> until next week after this stint of long work days.
>> 
>> cheers -ben
>> 
>>  
>> 
>> invalidateSessionData
>>handle atAllPut: 0. 
>> 
>> zero;s out the handle.  Cool.  However, 
>> 
>> handle isNull 
>> 
>> does not return true despite it being used in the getString method as 
>> 
>> ^ handle isNull
>>  ifTrue: ['external memory invalidated by session restart']
>>  ifFalse:[LibClang clang_getCString__cxString: self].
>> 
>> Looks like there should be an isNull on ByteArray that returns true if all 
>> bytes are zero but it isn't  there.  Was it dropped for some reason?
>> 
>> 
>> 
>>> On Oct 18, 2017, at 2:58 AM, Dimitris Chloupis >> > wrote:
>>> 
>>> Sure the documentation could be better, that is definetly important, but is 
>>> already good enough and UFFI is a very technical subject much more suited 
>>> to a mailing list . Its not physical possible to cover the massive 
>>> potential of UFFI.  
>>> 
>>> On Wed, Oct 18, 2017 at 9:32 AM Stephane Ducasse >> > wrote:
>>> Please do not hesitate to do Pull Requests.
>>> Luc told me that he wants to do a pass on it and Esteban promises that to me
>>> but he is super busy.
>>> 
>>> Stef
>>> 
>>> 
>>> On Wed, Oct 18, 2017 at 5:54 AM, Todd Blanchard >> > wrote:
>>> > Wonderful!  Thanks.
>>> >
>>> >> On Oct 17, 2017, at 3:45 PM, stephan >> >> > wrote:
>>> >>
>>> >> On 17-10-17 23:06, Todd Blanchard wrote:
>>> >>> Anyone know what happened to this?
>>> >>> https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/UnifiedFFI/UnifiedFFI.pdf
>>> >>>  
>>> >>> 
>>> >>
>>> >> https://github.com/SquareBracketAssociates/Booklet-uFFI 
>>> >> 
>>> >>
>>> >> has a link to a bintray pdf download
>>> >>
>>> >> Stephan
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>> 
>> 
>> 

Re: [Pharo-dev] OSWindow in Pharo 6.1 stable

[Ronie Salgado]

Hi Clément,

Last night I was checking again the VM. If I remove the hack in the
ioProcessEvents, I can receive the events with SDL2, but as soon as I type
on the main Pharo window I get a crash in an objective-c message send by
SDL2. I still need to debug SDL2 itself with debugging symbols.

I am not sure whether I will be able to fix the problem without modifying
SDL2. In the worst case escenario, we will have to move to the minheadless
vm.

Best regards,
Ronie

2017-10-18 4:49 GMT-03:00 Clément Bera :

> Hi again,
>
> I made many more attempts since those mails: I wrote this page
>  showing how to
> deploy my game in native app at 50fps on Linux, Mac and Windows.
>
> Currently I deploy with:
> Ubuntu 64 bits: Pharo61-64 (Pharo61-32 also works with the right lib
> installed)
> Mac OS X 64 bits: Pharo5Alpha-32 (On Pharo61 the keyboard events do not
> work correctly)
> Windows 64 bits: Pharo61-32 (There are bugs with the SDL2 window, the top
> bar is not displayed, but the game work. Reportedly it would work better
> with Pharo61-64 but the default Pharo64 VM on Windows still does not
> feature the JIT, once the default VM does, I will update).
>
> My goal is to deploy on all platforms with Pharo61-64 (and later
> Pharo7-64).
>
> I wrote this mail since maybe you are interested in knowing that with
> Pharo5Alpha-32 and the set-up described on the page of my game the keyboard
> events work fine on Mac, so it may be possible to write a fix for
> Pharo61/Pharo7 based on that.
>
> Best,
>
>
>
>
> On Fri, Sep 29, 2017 at 8:56 PM, Stephane Ducasse  > wrote:
>
>> Tx ronie!
>>
>>
>> On Fri, Sep 29, 2017 at 1:42 PM, Ronie Salgado 
>> wrote:
>> > Hi Clément,
>> >
>> > I just checked on my machine and it is also not working. It seems to be
>> a VM
>> > bug. It will take me some time to debug it. I have some suspicious on
>> > ioProcessEvents .
>> >
>> > Best regards,
>> > Ronie
>> >
>> > 2017-09-29 10:39 GMT+02:00 Clément Bera :
>> >>
>> >>
>> >>
>> >> On Fri, Sep 29, 2017 at 10:29 AM, Hilaire  wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> IMHO, it will make Pharo much more robust if core libraries as sdl,
>> >>> cairo, etc will be shipped with each plateform dependent virtual
>> machine and
>> >>> the image modified accordingly to use these core libraries.
>> >>
>> >>
>> >> That's how it is now but some of it is not working (Here SDL events and
>> >> there are 2 SDL2 libs by default).
>> >>
>> >> I think we should still have a minimal image starting with a minimal UI
>> >> without using FFI/SDL/Cairo or whatever lib. Else when we start on a
>> >> platform where one of this thing is not properly supported yet (See the
>> >> problem on the raspberry pie with some Pharo alpha version) it is too
>> hard
>> >> to understand what is going on.
>> >>
>> >>>
>> >>>
>> >>> The delivery of Pharo application to end users is an issue because of
>> >>> these recuring problem.
>> >>
>> >>
>> >> Honestly I was trying to write a doc on how to deploy Pharo client app
>> >> with SDL2 and Cairo but I have only a version working in Pharo 4 on
>> Mac and
>> >> Linux, while in theory I could have it working in Windows/Mac/Linux in
>> the
>> >> latest Pharo.
>> >>
>> >>>
>> >>> Hilaire
>> >>>
>> >>>
>> >>>
>> >>> Le 28/09/2017 à 15:02, Clément Bera a écrit :
>> 
>>  Btw for some reason in the one-click version of Pharo 32 bits on Mac
>>  there is 2 SDL plugins (libSDL2-2.0.0 and libSDL2), which leads to
>> conflicts
>>  (the VM use randomly one lib or the other). I randomly chose one
>> that I use
>>  and deleted the other one, do you have advises on which one I should
>> prefer
>>  ? Maybe the events are working only with the other one ?
>> 
>> >>>
>> >>> --
>> >>> Dr. Geo
>> >>> http://drgeo.eu
>> >>>
>> >>>
>> >>>
>> >>
>> >
>>
>>
>
>
> --
> Clément Béra
> Pharo consortium engineer
> https://clementbera.wordpress.com/
> Bâtiment B 40, avenue Halley 59650
> Villeneuve
> d
> 
> 'Ascq
> 
>

[Pharo-dev] Anoying bug fond in Artefact running in Windows 10

[casimiro.barreto]

When you insert a jpeg from a file, for some reason the file descriptor 
(stream) is kept open (at least in the Windows end of things). Then, if a 
second page is to be generated, the following error is shown: 

'MessageNotUnderstood: receiver of "reset" is nil

PDFJpegElement>>stream:
JPEGReadWriter
aJPEGReadWriter
JPEGReadWriter(ImageReadWriter)>>on:
nil

Sample code:

aPage := PDFPage new.

imageStream := FileStream fileNamed: 'lsi-tec.jpg'.

aPage
add:
((PDFJpegElement fromStream: imageStream)
from: 15 mm @ 20 mm;
dimension: 40 mm @ 40 mm).
imageStream close.

Generated report is in annex

The only way to recover is to close pharo, start it again. Then the file 
descriptor (stream) is released and it is possible to go on.

Has anyone faced this problem?
How to solve it?

Best regards,

Casimiro Barreto



ReqII09Ex01MHz-20171019141118.pdf
Description: Adobe PDF document

Re: [Pharo-dev] UnifiedFFI Docs

[Todd Blanchard]

That’s great - it’s been kind of magical but a couple things have changed since 
you wrote it and some bugs have crept into ffi.

Right now I’m finding the generated accessor for the VoidPointer3 is actually 
generating a void 3 accessor and that doesn’t work. I spent all day yesterday 
tracking it to the accessor generating code.

Sent from the road

> On Oct 18, 2017, at 22:29, Ben Coman  wrote:
> 
> 
> 
>> On Thu, Oct 19, 2017 at 1:05 AM, Todd Blanchard  wrote:
>> I'm working through Ben's great blog post about playing with libclang and I 
>> am puzzled by something.
> 
> Thx Todd. Knowing someone is looking at it encourages me to expand it.  
> I'm interested in looking at your specific questions, but it might not be 
> until next week after this stint of long work days.
> 
> cheers -ben
> 
>  
>> 
>> invalidateSessionData
>>handle atAllPut: 0. 
>> 
>> zero;s out the handle.  Cool.  However, 
>> 
>> handle isNull 
>> 
>> does not return true despite it being used in the getString method as 
>> 
>> ^ handle isNull
>>  ifTrue: ['external memory invalidated by session restart']
>>  ifFalse:[LibClang clang_getCString__cxString: self].
>> 
>> Looks like there should be an isNull on ByteArray that returns true if all 
>> bytes are zero but it isn't  there.  Was it dropped for some reason?
>> 
>> 
>> 
>>> On Oct 18, 2017, at 2:58 AM, Dimitris Chloupis  
>>> wrote:
>>> 
>>> Sure the documentation could be better, that is definetly important, but is 
>>> already good enough and UFFI is a very technical subject much more suited 
>>> to a mailing list . Its not physical possible to cover the massive 
>>> potential of UFFI.  
>>> 
>>> On Wed, Oct 18, 2017 at 9:32 AM Stephane Ducasse  
>>> wrote:
 Please do not hesitate to do Pull Requests.
 Luc told me that he wants to do a pass on it and Esteban promises that to 
 me
 but he is super busy.
 
 Stef
 
 
 On Wed, Oct 18, 2017 at 5:54 AM, Todd Blanchard  wrote:
 > Wonderful!  Thanks.
 >
 >> On Oct 17, 2017, at 3:45 PM, stephan  wrote:
 >>
 >> On 17-10-17 23:06, Todd Blanchard wrote:
 >>> Anyone know what happened to this?
 >>> https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/UnifiedFFI/UnifiedFFI.pdf
 >>
 >> https://github.com/SquareBracketAssociates/Booklet-uFFI
 >>
 >> has a link to a bintray pdf download
 >>
 >> Stephan
 >>
 >>
 >>
 >
 >
 
>> 
> 

Re: [Pharo-dev] open street map

[Stephane Ducasse]

Tx pavel.

On Wed, Oct 18, 2017 at 5:15 PM, Pavel Krivanek
 wrote:
> probably coordinates. This works:
> http://a.tile.openstreetmap.org/8/129/88.png
>
> -- Pavel
>
>
> 2017-10-18 17:04 GMT+02:00 Stephane Ducasse :
>>
>> Hi guys
>>
>> in the mooc I was used to use this expression
>>
>> http://a.tile.openstreetmap.org/8/12/8.png
>>
>> and now I get an empty tile and I wonder why. May openstreet map changed
>> their policy.
>>
>> Did any of you experience the same?
>>
>> Stef
>>
>

Re: [Pharo-dev] Loading GToolkit is broken in latest 7

[Stephane Ducasse]

I would suggest to load pillar based on version and stable version. I
never try development especially because
I'm maintaining branches in MC which does not support branches.

Setf

On Thu, Oct 19, 2017 at 12:05 PM, Alistair Grant  wrote:
> Hi Steph,
>
> On 19 October 2017 at 11:56, stephan  wrote:
>> Iceberg enableMetacelloIntegration: true.
>> Metacello new
>> baseline: 'GToolkit';
>> repository: 'github://feenkcom/gtoolkit/src';
>> load.
>>
>> tries to resolve ConfigurationOfGrease to #release1
>>
>> Stephan
>
> I've hit exactly the same issue.
>
> It looks like ConfigurationOfGrease is missing #pharo7.x version
> identifiers throughout it.
>
> I took a guess at the required changes (in the attached file), but
> have hit several other problems with Pillar that I'm still working
> through, e.g. at the start of October, loading Pillar with:
>
>
> spec
> project: 'Pillar' with: [
> spec
> className: #ConfigurationOfPillar;
> versionString: #'development';
> repository: 'http://smalltalkhub.com/mc/Pier/Pillar/main' ].
>
>
> loaded Grease-Pharo30-Core.  But now it doesn't.
>
>
> Cheers,
> Alistair

Re: [Pharo-dev] Loading GToolkit is broken in latest 7

[Stephane Ducasse]

Hi

About pillar I'm working on it.
Now I only maintain two versions one for Pharo 50 and one for Pharo 60.
The new things are happening in Pharo 60.
Now this was a bad idea to link Pillar with Magritte only to manage
configurations
 because Magritte is too big to me and full of too many constraints
like loading Grease and others.
I do not want to spend my time fighting with issues imposed to me.

I'm slowly working on freeing Pillar from Magritte but I got stuck and
out of energy.
Now I will not maintain a version for Pharo 70 alpha because I simply cannot.

Stef


On Thu, Oct 19, 2017 at 12:05 PM, Alistair Grant  wrote:
> Hi Steph,
>
> On 19 October 2017 at 11:56, stephan  wrote:
>> Iceberg enableMetacelloIntegration: true.
>> Metacello new
>> baseline: 'GToolkit';
>> repository: 'github://feenkcom/gtoolkit/src';
>> load.
>>
>> tries to resolve ConfigurationOfGrease to #release1
>>
>> Stephan
>
> I've hit exactly the same issue.
>
> It looks like ConfigurationOfGrease is missing #pharo7.x version
> identifiers throughout it.
>
> I took a guess at the required changes (in the attached file), but
> have hit several other problems with Pillar that I'm still working
> through, e.g. at the start of October, loading Pillar with:
>
>
> spec
> project: 'Pillar' with: [
> spec
> className: #ConfigurationOfPillar;
> versionString: #'development';
> repository: 'http://smalltalkhub.com/mc/Pier/Pillar/main' ].
>
>
> loaded Grease-Pharo30-Core.  But now it doesn't.
>
>
> Cheers,
> Alistair

Re: [Pharo-dev] Loading GToolkit is broken in latest 7

[stephan]

On 19-10-17 14:23, Aliaksei Syrel wrote:
Something changed in Pharo 7 between 06.10.2017 - 17.10.2017 because 
GToolkit it loads flawlessly in Pharo from 6th of October.


Looks most likely to be build 197:

There is a new Pharo build available!

The status of the build #197 was: SUCCESS.

The Pull Request #362 was integrated: 
"20540-move-metacelloPlatformAttributes-to-Pharo7"

Pull request url: https://github.com/pharo-project/pharo/pull/362

Issue Url: https://pharo.fogbugz.com/f/cases/20540
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/197/

Re: [Pharo-dev] Loading GToolkit is broken in latest 7

[stephan]

On 19-10-17 13:32, Alistair Grant wrote:


That loads successfully for me, thanks, but Pillar & Magritte are
broken in new and interesting ways.  It will be a while before I can
look in to it properly.


The #pier and Magritte 3.5.0 references are not helpful there, and it 
looks like there are more pharo7 tags missing


Stephan

Re: [Pharo-dev] Loading GToolkit is broken in latest 7

[Alistair Grant]

Hi Stephan,

On 19 October 2017 at 12:45, stephan  wrote:
> On 19-10-17 12:21, stephan wrote:
>>
>> On 19-10-17 12:05, Alistair Grant wrote:
>>
>>> I've hit exactly the same issue.
>>>
>>> It looks like ConfigurationOfGrease is missing #pharo7.x version
>>> identifiers throughout it.
>
>
> Name: ConfigurationOfGrease-StephanEggermont.347
> Author: StephanEggermont
> Time: 19 October 2017, 12:42:22.848053 pm
> UUID: baaf8ebf-4518-0d00-ab4f-cad309d94048
> Ancestors: ConfigurationOfGrease-JohanBrichau.346
>
> Added Pharo 7 versions of release1/1.3

That loads successfully for me, thanks, but Pillar & Magritte are
broken in new and interesting ways.  It will be a while before I can
look in to it properly.

Thanks,
Alistair

Re: [Pharo-dev] Loading GToolkit is broken in latest 7

[stephan]

On 19-10-17 12:21, stephan wrote:

On 19-10-17 12:05, Alistair Grant wrote:


I've hit exactly the same issue.

It looks like ConfigurationOfGrease is missing #pharo7.x version
identifiers throughout it.


Name: ConfigurationOfGrease-StephanEggermont.347
Author: StephanEggermont
Time: 19 October 2017, 12:42:22.848053 pm
UUID: baaf8ebf-4518-0d00-ab4f-cad309d94048
Ancestors: ConfigurationOfGrease-JohanBrichau.346

Added Pharo 7 versions of release1/1.3

Re: [Pharo-dev] Loading GToolkit is broken in latest 7

[stephan]

On 19-10-17 12:05, Alistair Grant wrote:


I've hit exactly the same issue.

It looks like ConfigurationOfGrease is missing #pharo7.x version
identifiers throughout it.


BaselineOfGToolkitDocumenter refers to ConfigurationOfPillar #pier 
version. That is very, very old. Pillar broke compatibility years ago


ConfigurationOfPillar does not look good at all:

- no pharo 7 in stable, and a strange common version.
- in the stable version 6.0.6 all dependencies are to numbered versions 
instead of symbolic ones.


ConfigurationOfCocoon has the same problem, pointing to Magritte3 3.5.0


I could load by defining #'pharo7' versions in #'release1' and #'release1.3'

Stephan

[Pharo-dev] Loading GToolkit is broken in latest 7

[stephan]

Iceberg enableMetacelloIntegration: true.
Metacello new
baseline: 'GToolkit';
repository: 'github://feenkcom/gtoolkit/src';
load.

tries to resolve ConfigurationOfGrease to #release1

Stephan

[Pharo-dev] [Pharo 7.0-dev] Build #210: 19533-Configuration-command-line-handler-should-not-save-and-quit-by-himself

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #210 was: SUCCESS.

The Pull Request #376 was integrated: 
"19533-Configuration-command-line-handler-should-not-save-and-quit-by-himself"
Pull request url: https://github.com/pharo-project/pharo/pull/376

Issue Url: https://pharo.fogbugz.com/f/cases/19533
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/210/

[Pharo-dev] Management of ctrl + shift in windows

[Cyril Ferlicot D.]

Hi,

I have a weird problem on Windows and shortcuts.

For the context I use a keyboard which is not of the AZERTY/QWERTY
layout but BÉPO.[1]

I have a problem with the fact that some `ctrl + shift + ?` shortucts
does not works. But some works.

For example in Nautilus I cannot do a format (`ctrl + shift + f`) or a
debug it (`ctrl + shift + d`). In the other hand, in Spotter I can drill
down a category with `ctrl + shift + ->`.

If I use the AZERTY layout I do not have this problem.

I tried to use the KeyPrinterMorph and to do the format shortcut. Here
is the result:

BÉPO:
- Key SHIFT_L code: (65505)
- Key CONTROL_L code: (65507)
- Key F code: (70)

AZERTY:
- Key SHIFT_L code: (65505)
- Key CONTROL_L code: (65507)
- Key F code: (70)

So this is the same key events.

I don't have the knowledge and the time to investigate this.  Maybe
someone have some idea of where can be the problem?

https://pharo.fogbugz.com/f/cases/20555/Bug-in-the-ctrl-shift-shortcuts-in-Windows


[1] http://typematrix.com/bepo/view_closeup.php?l=&t=keyb&id=0

-- 
Cyril Ferlicot
https://ferlicot.fr

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

[Pharo-dev] Zerconf download of source files in Pharo 7

[Torsten Bergmann]

When I run 

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

the zeroconf script downloads image bundle, VM bundle and sources archive: 

   
   Downloading the latest 70 Image:
  http://files.pharo.org/get-files/70/pharo.zip

   Pharo.image
   Downloading the latest pharoVM:
   http://files.pharo.org/get-files/70/pharo-linux-stable.zip
   pharo-vm/pharo
   Downloading PharoV70.sources:
   http://files.pharo.org/get-files/70/sources.zip
   Creating starter scripts pharo and pharo-ui
   ...
   


Now in Pharo 7 the pharo.zip already includes the sources. Right?
See attached screenshot.

So why is the zeroconf additionally downloading the sources.zip
which IMHO is an unnecessary additional download now.

Maybe because it was necessary in the past and the zeroconf was
not adopted. 

Anyone able to check and maybe remove the additional download for Pharo 7?

Thx
T.

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

[Guillermo Polito]

On Thu, Oct 19, 2017 at 1:36 AM, Hernán Morales Durand <
hernan.mora...@gmail.com> wrote:

> Thanks Guille, now it looks fine.
>
> Another issue for Windows users is that you cannot execute the workaround:
>
> $ git config core.longpaths true
>
> until you first cloned the repository. That's why I said one first should
> let fail the git clone command and then:
>
> $ cd pharo/
> $ git config core.longpaths true
> $ git checkout -f HEAD
>
> If anyone can check because submitting a fix should be easy and there
> shouldn't be guessing in the process.
>

If a windows user confirms, I update it. I don't have access to a windows
machine right now :).

>
> Cheers,
>
> Hernán
>
>
> 2017-10-18 4:37 GMT-03:00 Guillermo Polito :
>
>>
>>
>> On Tue, Oct 17, 2017 at 12:42 PM, Hernán Morales Durand <
>> hernan.mora...@gmail.com> wrote:
>>
>>> Thank you Esteban, that was the problem! :)
>>>
>>> Maybe guille wants to clarify the correct remote repository in the page:
>>> https://github.com/guillep/PharoIntegrationProcess/wiki/Cont
>>> ribute-a-fix-to-Pharo after "You can click on the *Add remote* option
>>> and configure a remote with a name and repository url."
>>>
>>
>> Done that.
>>
>> Can you check if that's ok?
>>
>>
>>>
>>> Another thing. I created a PR with a fix for this bug :
>>> https://pharo.fogbugz.com/f/cases/17754/CheckBoxModel-RadioB
>>> uttonModel-ignore-disable following the guide to the Step 3. However I
>>> couldn't view any PR in my Github page (see attach).
>>>
>>> Do I miss something?
>>>
>>>
>>> 2017-10-17 6:53 GMT-03:00 Esteban Lorenzano :
>>>
 no is ok.
 with the pharo version I know the iceberg version :)

 anyway your problem is that the remote for pharo is bad.

 you added g...@github.com:pharo/pharo.git and I do not think that
 exists.
 Correct one is:

 g...@github.com:pharo-project/pharo.git

 Esteban


 On 17 Oct 2017, at 11:51, Hernán Morales Durand <
 hernan.mora...@gmail.com> wrote:

 I don't see any easy way to find the Iceberg version.

 Should I update Iceberg using this script also in Pharo 7?

 "Restore defaults"
 Iceberg enableMetacelloIntegration: false.
 MetacelloPharo30Platform select.

 "Update metacello"
 Metacello new
   baseline: 'Metacello';
   repository: 'github://metacello/metacello:Pharo6.1/repository';
   onConflict: [:e | e useIncoming ];
   get;
   load.

 "Update iceberg"
  #(
 'Iceberg-UI'
 'Iceberg-Plugin-GitHub'
 'Iceberg-Plugin'
 'Iceberg-Metacello-Integration'
 'Iceberg-Libgit-Tonel'
 'Iceberg-Libgit-Filetree'
 'Iceberg-Libgit'
 'Iceberg'
 'LibGit-Core')
 do: [ :each | (each asPackageIfAbsent: [ nil ]) ifNotNil:
 #removeFromSystem ].
 Metacello new
   baseline: 'Iceberg';
   repository: 'github://pharo-vcs/iceberg:v0.6';
   load.

 2017-10-17 6:46 GMT-03:00 Hernán Morales Durand <
 hernan.mora...@gmail.com>:

> Hi Esteban,
>
> This one:
>
> wget -O- get.pharo.org/70+vm | bash -
>
> 2017-10-17 3:36 GMT-03:00 Esteban Lorenzano :
>
>> which Pharo version (and Iceberg version) do you have?
>>
>> Esteban
>>
>> On 17 Oct 2017, at 04:36, Hernán Morales Durand <
>> hernan.mora...@gmail.com> wrote:
>>
>> Hi Guille,
>>
>> In https://github.com/guillep/PharoIntegrationProcess/wiki/Cont
>> ribute-a-fix-to-Pharo
>>
>> This part is not working for me: "Go back to iceberg, right click on
>> the pharo repository and go to the *Pharo* entry. You'll see the
>> option *Create new branch from Fogbugz issue*."
>>
>> Because there is no such "Pharo" option in the menu. See the attached
>> screenshot.
>>
>> Did I miss something?
>> Any suggestion?
>>
>>
>> 2017-08-10 12:17 GMT-03: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.
>>>
>>> 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
>>
>> Centre de Recherche en Informatique, Signal et Automatique de Lille
>>
>> CRIStAL - UMR 9189
>>
>> French National Center for Scienti