Re: [Pharo-dev] Code Completion

[Torsten Bergmann]

Hi Myroslava,

some infos:
 
Initially for Squeak there was "eCompletion" written by Ruben Bakker. According 
to the package "eCompletion is code 
completion inspired by eclipse", it required MCInstaller, Shout 4 and RoelTyper.
http://uncomplex.net/ecompletion/

Back in Squeak "Shout" was used to have syntax highlighting as you type.
RoelTyper is a fast type reconstructor for Smalltalk (name comes from its 
Author Roel Wuyts)
https://roelwuyts.be/roeltyper/index.html
https://www.youtube.com/watch?v=CvKTCSv7s8s

Later oCompletion followed - "OCompletion builds on ECompletion and improves 
its accuracy."
http://www.squeaksource.com/OCompletion/
http://www.inf.unisi.ch/phd/robbes/papers/ASE2008-completion.pdf
OCompletion uses (based on recent activity) considerably improves the accuracy 
of code completion. That is, 
the actual selector you want to insert is usually in the top 3 matches 
OCompletion proposes.
https://news.squeak.org/tag/ocompletion/

A paper you should read is
https://users.dcc.uchile.cl/~rrobbes/p/JASE-completion.pdf
OCompletion is a re-working of the venerable eCompletion package, based on 
research done by Romain Robbes and Michele Lanza.

OCompletion is in Pharo since Pharo 2.0
There already was a discussion about better completion back in 2015
https://www.mail-archive.com/pharo-users@lists.pharo.org/msg14835.html based on 
the need for pluggability
(https://pharo.fogbugz.com/f/cases/13124/NECContext-needs-plugin-design) and 
basing it on AST instead of Shout
https://pharo.fogbugz.com/f/cases/10219/Completion-enter-on-accept-awkwardness

So NECController is the old code and NOCController (there was a setting to 
change from one to the other)
ECompletion was just a list of matching classes/selectors. OCompletion added 
some candy like showing first last typed entries 
(with some other heuristic).

http://www.jarober.com/blog/blogView?showComments=true=ST+4U+46%3A+Autocomplete+in+Pharo=3474862713


What I always liked in Eclipse compared to Pharo is that you can code complete 
an expression and
the parameters are visualized with a rectangle and by "tabbing" you can fill 
each of them:

https://www.youtube.com/watch?v=OMbVQcZ0gV8

Also one can do own code templates who are used in the completion then:
https://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.cdt.doc.user%2Ftasks%2Fcdt_t_add_codetemp.htm


Some other alternatives: CACHECA is a cache language model based code 
suggestion tool (https://github.com/christinef/CACHECA) for Eclipse
which could be seen in https://www.youtube.com/watch?v=3INk0N3JNtc

RubyMine code completion for Ruby
https://www.jetbrains.com/help/ruby/auto-completing-code.html


Thanks
T.

Gesendet: Donnerstag, 25. Januar 2018 um 22:52 Uhr
Von: "Myroslava Romaniuk" 
An: "Pharo Development List" 
Betreff: [Pharo-dev] Code Completion

Hi, I'm Myroslava
 
Some of you might remember how last year I did GSoC and worked on Renraku / 
Quality Assistant with Yuriy.
 
This year Stephane suggested several projects I could work on, and one of them 
is improving code completion in Pharo, in particular ecompletion. Could you 
recommend any resources that would help me better understand how it works? I'd 
also like to know what's the difference between ecompletion and ocompletion, 
and what's NOC and NEC completion, as it doesn't seem very clear to me so far?
 
If any of you worked on it and can help me get started, I would really 
appreciate it.
 
Thanks

Re: [Pharo-dev] How to get rid of empty XML nodes?

[monty]

See #removeAllFormattingNodes and its comment in the latest version.

And instances of SAXHandler and subclasses are meant to be created with #on: 
(or another "instance creation" message), _not #new_, otherwise they won't be 
properly initialized. The class comment is clear about this, but I should have 
overridden #new to raise an error like Stream does. Your misuse was helpful in 
bringing this to my attention, and I added a Stream-like #new implementation to 
SAXHandler.

> Sent: Friday, December 08, 2017 at 9:21 AM
> From: "Stephane Ducasse" 
> To: "Pharo Development List" 
> Subject: Re: [Pharo-dev] How to get rid of empty XML nodes?
>
> Hi monty
> 
> 
> On Fri, Dec 8, 2017 at 9:03 AM, monty  wrote:
> > By "empty XML nodes," do you mean whitespace-only string nodes?
> 
> Yes
> 
> > Those are included because all in-element whitespace is assumed significant 
> > by the spec: https://www.w3.org/TR/xml/#sec-white-space
> 
> I know. There was a discussion a while ago. I just lost a couple of
> hours understanding that :(
> 
> But this is a super super super annoying practices.
> We had to test each nodes to see if it is a empty nodes so it makes
> everything a lot more complex without real justification
> beside the fact that these standardizers probably never implemented
> some real cases.
> This standard is a really out of reality from that perspective.
> 
> > The exception is if the element is declared in the DTD as only having 
> > element children ("element content"): 
> > https://www.w3.org/TR/xml/#dt-elemcontent
> 
> Well the XML files that I had (I did not choose XML because I would
> have prefer JSON :) ), had no DTD :(
> 
> So at the end of the day, this wonderful standard puts all the stress
> and burden to people.
> 
> >
> > For example, if you declare an element like this:
> >
> > 
> >
> > Any whitespace around a "two," "three," or "four" element child of a "one" 
> > element is insignificant and ignored (unless #preservesIgnorableWhitespace: 
> > is true). Other parsers, like LibXML2 and Xerces, behave the same way.
> >
> > I'll see if I can come up with some easier way to deal with this, like an 
> > optional parser setting, new enumeration methods, or maybe a tree 
> > transformation.
> 
> It would be A HUGE PLUS!!
> 
> 
> Because reality is that people have XML files with just nodes and no
> empty nodes and they are forced to
> Let me know because I could try.
> 
> I was showing how to use Pharo to import code to pharo learners and
> this was a big drag.
> 
> Stef
> 
> 
> I tried to set some values in the parser but it did not work.
> BTW I saw that the configuration logic forces to write the following
> 
> | parser doc visitor |
> parser := XMLDOMParser new
>on: self xmlContents;
>preservesIgnorableWhitespace: true.
> 
> and not
> 
> | parser doc visitor |
> parser := XMLDOMParser new
> preservesIgnorableWhitespace: true.
> on: self xmlContents;
> 
> 
> >
> >> Sent: Tuesday, December 05, 2017 at 8:29 AM
> >> From: "Stephane Ducasse" 
> >> To: "Pharo Development List" 
> >> Subject: [Pharo-dev] How to get rid of empty XML nodes?
> >>
> >> )Hi
> >>
> >> we are manipulating an XML document and I would like to get rid of the
> >> spurious empty string.
> >> We saw that the gt panes are doing it.
> >>
> >> (aNodeWithElements isStringNode
> >> and: [aNodeWithElements isEmpty
> >> or: [aNodeWithElements isWhitespace]]
> >>
> >> Is there a way not to produce empty nodes?
> >> Is there a simple way not to have to handle them
> >>
> >> Now each time we are dealing with a node with have to check.
> >>
> >> Stef
> >>
> >>
> >
> 
> 

Re: [Pharo-dev] Iceberg Loading issue

[Vincent BLONDEAU]

Hi Max,

 

Yes, I tried that too: pulling the branch outside Pharo, set it to the 21124 
branch head, then launch Pharo and run the pull of incoming commits from Pharo.

Also, loading one commit at the time works, but you cannot do it for a lot of 
commits, the list of commits is very slow to refresh (at least under Windows).

 

Cheers,

Vincent 

 

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Max 
Leske
Sent: jeudi 25 janvier 2018 22:15
To: Pharo Development List
Subject: Re: [Pharo-dev] Iceberg Loading issue

 

Hi Vincent,

 

Possibly a problem with updating FETCH_HEAD. Does it work when you perform only 
the pull operation from Pharo (i.e., check out the branch on the command line)?

 

 

Cheers,

Max

 

 

 

On 26 January 2018 at 00:43:40, vincent.blond...@lamresearch.com 
  (vincent.blond...@lamresearch.com 
 ) wrote:

Hi, 

I am encountering some problems with Iceberg on the latest version. 

I want to load the commits I just made on a branch on my Pharo fork, let's say 
"21124". I set the local repo to the current version of my Pharo image, i.e. 
the development branch (commit 0dbf86). 
Thanks to the iceberg interface, I change the current branch to "21124", there 
are 12 commits that are incoming. 
Then, I then do "Pull incoming commit" to load them. 
But after a few moment, instead of loading only the delta between the 
development branch and the "21124" one, iceberg goes further in the commit 
history and wants to load 174 commits... Including one that does not load. 

By debugging, it seems that there is a problem with 
LGitRepository>>fastForward:, the result of "self lookup: 'FETCH_HEAD'" gives 
not the good commit i.e. the one of the development branch (commit 0dbf86), but 
instead the one of "I do not what". 

Does this issue is known? And how can I bypass it or solve it? 

Thanks, 

Vincent 

Re: [Pharo-dev] Iceberg Loading issue

[Max Leske]

Hi Vincent,

Possibly a problem with updating FETCH_HEAD. Does it work when you perform
only the pull operation from Pharo (i.e., check out the branch on the
command line)?


Cheers,
Max



On 26 January 2018 at 00:43:40, vincent.blond...@lamresearch.com (
vincent.blond...@lamresearch.com) wrote:

Hi,

I am encountering some problems with Iceberg on the latest version.

I want to load the commits I just made on a branch on my Pharo fork, let's
say "21124". I set the local repo to the current version of my Pharo image,
i.e. the development branch (commit 0dbf86).
Thanks to the iceberg interface, I change the current branch to "21124",
there are 12 commits that are incoming.
Then, I then do "Pull incoming commit" to load them.
But after a few moment, instead of loading only the delta between the
development branch and the "21124" one, iceberg goes further in the commit
history and wants to load 174 commits... Including one that does not load.

By debugging, it seems that there is a problem with
LGitRepository>>fastForward:, the result of "self lookup: 'FETCH_HEAD'"
gives not the good commit i.e. the one of the development branch (commit
0dbf86), but instead the one of "I do not what".

Does this issue is known? And how can I bypass it or solve it?

Thanks,

Vincent

[Pharo-dev] Iceberg Loading issue

[Vincent.Blondeau]

Hi,

I am encountering some problems with Iceberg on the latest version.

I want to load the commits I just made on a branch on my Pharo fork, let's say 
"21124". I set the local repo to the current version of my Pharo image, i.e. 
the development branch (commit 0dbf86).
Thanks to the iceberg interface, I change the current branch to "21124", there 
are 12 commits that are incoming.
Then, I then do "Pull incoming commit" to load them.
But after a few moment, instead of loading only the delta between the 
development branch and the "21124" one, iceberg goes further in the commit 
history and wants to load 174 commits... Including one that does not load.

By debugging, it seems that there is a problem with 
LGitRepository>>fastForward:, the result of "self lookup: 'FETCH_HEAD'" gives 
not the good commit i.e. the one of the development branch  (commit 0dbf86), 
but instead the one of "I do not what".

Does this issue is known? And how can I bypass it or solve it?

Thanks,

Vincent
<>

[Pharo-dev] Code Completion

[Myroslava Romaniuk]

Hi, I'm Myroslava

Some of you might remember how last year I did GSoC and worked on Renraku /
Quality Assistant with Yuriy.

This year Stephane suggested several projects I could work on, and one of
them is improving code completion in Pharo, in particular ecompletion.
Could you recommend any resources that would help me better understand how
it works? I'd also like to know what's the difference between ecompletion
and ocompletion, and what's NOC and NEC completion, as it doesn't seem very
clear to me so far?

If any of you worked on it and can help me get started, I would really
appreciate it.

Thanks

Re: [Pharo-dev] [Ann] Calypso in progress: Spotter menu and settings

[Esteban Lorenzano]

> On 25 Jan 2018, at 22:18, Esteban Lorenzano  wrote:
> 
> 
> 
>> On 25 Jan 2018, at 21:57, Stephane Ducasse  wrote:
>> 
>> Hi
>> I like the navigation done with Spotter by esteban
>> Now can we see the shortcuts? and get the notification when we do not
>> use a shortcut because this is super nice to learn shortcuts.
> 
> yes, that’s something we need to add. 
> (also, we need to add shortcuts… there are too few)

just to be clear, the spotter navigation is not a replacement: is a complement. 
and I made it because I realise we will always have more actions than shortcuts 
possible, so the idea is to define shortcuts for most common tasks and make 
reachable (and understandable) the others.

> 
> Esteban
> 
>> 
>> On Thu, Jan 25, 2018 at 1:28 PM, Tudor Girba  wrote:
>>> Excellent work!
>>> 
>>> Doru
>>> 
>>> 
 On Jan 25, 2018, at 1:25 PM, Denis Kudriashov  wrote:
 
 Hi,
 
 I just released new version of Calypso 0.8.11 which includes several fixes 
 and new features.
 
 The most exiting feature is Spotter menu from Esteban 
 https://youtu.be/RgqiSRFUAIk:
 
 "Spotter navigation" brings an easy way to access all available panels, 
 tabs and commands in selected browser.
 Activation is usually cmd+/ (because is close to the arrows)
 
 Settings browser includes group for Calypso:
 
 - trait method visibility (enabled by default)
 - hierarchy order for variables (variable mode in full browser)
 - hierarchy order of method visibility classes (when expand first item in 
 method groups pane)
 - shortcut for spotter menu. It is temporal solution until Commander will 
 provide settings for all shortcuts in system.
 
 And few other improvements:
 - better status bar tool to change protocol and package
 - shortcut to change ineditor method protocol: $e meta , $t meta (editor + 
 tag)
 - shortcut to change ineditor method package: $e meta, $p meta (editor + 
 package)
 - inherited method group is replaced by all methods group with name 
 "instance side" or "class side" depending on browser mode. It should make 
 browser meta level more noticeable.
 
 Best regards,
 Denis
>>> 
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>> 
>>> "Things happen when they happen,
>>> not when you talk about them happening."
>>> 
>>> 
>> 
> 

Re: [Pharo-dev] [Ann] Calypso in progress: Spotter menu and settings

[Esteban Lorenzano]

> On 25 Jan 2018, at 21:57, Stephane Ducasse  wrote:
> 
> Hi
> I like the navigation done with Spotter by esteban
> Now can we see the shortcuts? and get the notification when we do not
> use a shortcut because this is super nice to learn shortcuts.

yes, that’s something we need to add. 
(also, we need to add shortcuts… there are too few)

Esteban

> 
> On Thu, Jan 25, 2018 at 1:28 PM, Tudor Girba  wrote:
>> Excellent work!
>> 
>> Doru
>> 
>> 
>>> On Jan 25, 2018, at 1:25 PM, Denis Kudriashov  wrote:
>>> 
>>> Hi,
>>> 
>>> I just released new version of Calypso 0.8.11 which includes several fixes 
>>> and new features.
>>> 
>>> The most exiting feature is Spotter menu from Esteban 
>>> https://youtu.be/RgqiSRFUAIk:
>>> 
>>> "Spotter navigation" brings an easy way to access all available panels, 
>>> tabs and commands in selected browser.
>>> Activation is usually cmd+/ (because is close to the arrows)
>>> 
>>> Settings browser includes group for Calypso:
>>> 
>>> - trait method visibility (enabled by default)
>>> - hierarchy order for variables (variable mode in full browser)
>>> - hierarchy order of method visibility classes (when expand first item in 
>>> method groups pane)
>>> - shortcut for spotter menu. It is temporal solution until Commander will 
>>> provide settings for all shortcuts in system.
>>> 
>>> And few other improvements:
>>> - better status bar tool to change protocol and package
>>> - shortcut to change ineditor method protocol: $e meta , $t meta (editor + 
>>> tag)
>>> - shortcut to change ineditor method package: $e meta, $p meta (editor + 
>>> package)
>>> - inherited method group is replaced by all methods group with name 
>>> "instance side" or "class side" depending on browser mode. It should make 
>>> browser meta level more noticeable.
>>> 
>>> Best regards,
>>> Denis
>> 
>> --
>> www.tudorgirba.com
>> www.feenk.com
>> 
>> "Things happen when they happen,
>> not when you talk about them happening."
>> 
>> 
> 

Re: [Pharo-dev] [Ann] Calypso in progress: Spotter menu and settings

[Stephane Ducasse]

Hi
I like the navigation done with Spotter by esteban
Now can we see the shortcuts? and get the notification when we do not
use a shortcut because this is super nice to learn shortcuts.

On Thu, Jan 25, 2018 at 1:28 PM, Tudor Girba  wrote:
> Excellent work!
>
> Doru
>
>
>> On Jan 25, 2018, at 1:25 PM, Denis Kudriashov  wrote:
>>
>> Hi,
>>
>> I just released new version of Calypso 0.8.11 which includes several fixes 
>> and new features.
>>
>> The most exiting feature is Spotter menu from Esteban 
>> https://youtu.be/RgqiSRFUAIk:
>>
>> "Spotter navigation" brings an easy way to access all available panels, tabs 
>> and commands in selected browser.
>> Activation is usually cmd+/ (because is close to the arrows)
>>
>> Settings browser includes group for Calypso:
>>
>> - trait method visibility (enabled by default)
>> - hierarchy order for variables (variable mode in full browser)
>> - hierarchy order of method visibility classes (when expand first item in 
>> method groups pane)
>> - shortcut for spotter menu. It is temporal solution until Commander will 
>> provide settings for all shortcuts in system.
>>
>> And few other improvements:
>> - better status bar tool to change protocol and package
>> - shortcut to change ineditor method protocol: $e meta , $t meta (editor + 
>> tag)
>> - shortcut to change ineditor method package: $e meta, $p meta (editor + 
>> package)
>> - inherited method group is replaced by all methods group with name 
>> "instance side" or "class side" depending on browser mode. It should make 
>> browser meta level more noticeable.
>>
>> Best regards,
>> Denis
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Things happen when they happen,
> not when you talk about them happening."
>
>

[Pharo-dev] 64 bit VM build problems: gl.h not found, or glRenderer conflicts

[Alistair Grant]

Hi,

I'm attempting to build the 64 bit VM in a docker container on Ubuntu
16.04 installing the required packages using
opensmalltalk-vm/.travis_install.sh, however B3DAcceleratorPlugin
fails to build because it can't find gl.h.

Installing mesa-common-dev (which is the most common answer when
searching for missing gl.h on google) changes the error to glRenderer
is redefined and has conflicting types.

Does anyone know what the correct combination of packages is?

Thanks!
Alistair

[Pharo-dev] [Pharo 7.0-dev] Build #454: 21128-FastTable-search-should-not-setup-first-selected-item-if-nothing-is-found

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #454 was: SUCCESS.

The Pull Request #732 was integrated: 
"21128-FastTable-search-should-not-setup-first-selected-item-if-nothing-is-found"
Pull request url: https://github.com/pharo-project/pharo/pull/732

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

[Pharo-dev] [Pharo 7.0-dev] Build #453: 21116 Super tearDown need to be called as last message in tearDown of VSReleaseDevelopmentVersionCommandTest

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #453 was: SUCCESS.

The Pull Request #717 was integrated: "21116 Super tearDown need to be called 
as last message in tearDown of VSReleaseDevelopmentVersionCommandTest"
Pull request url: https://github.com/pharo-project/pharo/pull/717

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

[Pharo-dev] [Pharo 7.0-dev] Build #452: 20929 Remove unnecessary "self debug:#testSelector" comment from test methods - PASS 1

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #452 was: SUCCESS.

The Pull Request #649 was integrated: "20929 Remove unnecessary "self 
debug:#testSelector" comment from test methods - PASS 1"
Pull request url: https://github.com/pharo-project/pharo/pull/649

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

[Pharo-dev] [Pharo 7.0-dev] Build #451: 21059-Make-icon-list-searchable

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #451 was: SUCCESS.

The Pull Request #730 was integrated: "21059-Make-icon-list-searchable"
Pull request url: https://github.com/pharo-project/pharo/pull/730

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

Re: [Pharo-dev] [Ann] Calypso in progress: Spotter menu and settings

[Tudor Girba]

Excellent work!

Doru


> On Jan 25, 2018, at 1:25 PM, Denis Kudriashov  wrote:
> 
> Hi,
> 
> I just released new version of Calypso 0.8.11 which includes several fixes 
> and new features.
> 
> The most exiting feature is Spotter menu from Esteban 
> https://youtu.be/RgqiSRFUAIk: 
> 
> "Spotter navigation" brings an easy way to access all available panels, tabs 
> and commands in selected browser.
> Activation is usually cmd+/ (because is close to the arrows)
> 
> Settings browser includes group for Calypso:
> 
> - trait method visibility (enabled by default)
> - hierarchy order for variables (variable mode in full browser)
> - hierarchy order of method visibility classes (when expand first item in 
> method groups pane)
> - shortcut for spotter menu. It is temporal solution until Commander will 
> provide settings for all shortcuts in system.
> 
> And few other improvements:
> - better status bar tool to change protocol and package
> - shortcut to change ineditor method protocol: $e meta , $t meta (editor + 
> tag)
> - shortcut to change ineditor method package: $e meta, $p meta (editor + 
> package)
> - inherited method group is replaced by all methods group with name "instance 
> side" or "class side" depending on browser mode. It should make browser meta 
> level more noticeable.
> 
> Best regards,
> Denis

--
www.tudorgirba.com
www.feenk.com

"Things happen when they happen,
not when you talk about them happening."

[Pharo-dev] [Pharo 7.0-dev] Build #450: 21034 ep monitor classreset should not create a new instance if current is already empty

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #450 was: SUCCESS.

The Pull Request #698 was integrated: "21034 ep monitor classreset should not 
create a new instance if current is already empty"
Pull request url: https://github.com/pharo-project/pharo/pull/698

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

[Pharo-dev] [Pharo 7.0-dev] Build #449: 21065 Super setUp need to be called in HiNodesAndLinksIteratorWithOneLinkModelTest

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #449 was: SUCCESS.

The Pull Request #712 was integrated: "21065 Super setUp need to be called in 
HiNodesAndLinksIteratorWithOneLinkModelTest"
Pull request url: https://github.com/pharo-project/pharo/pull/712

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

[Pharo-dev] [Pharo 7.0-dev] Build #448: 21106 Super tearDown need to be called as last message in tearDown of PharoTutorial tests

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #448 was: SUCCESS.

The Pull Request #725 was integrated: "21106 Super tearDown need to be called 
as last message in tearDown of PharoTutorial tests"
Pull request url: https://github.com/pharo-project/pharo/pull/725

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

[Pharo-dev] [ANN] Pharo Consortium New Gold Member: KnowRoaming

[Marcus Denker]

The Pharo Consortium is very happy to announce that KnowRoaming
has joined the Consortium as a Gold Member.

About
- KnowRoaming: https://www.knowroaming.com
- Pharo Consortium: http://consortium.pharo.org

The goal of the Pharo Consortium is to allow companies and institutions to
support the ongoing development and future of Pharo.

Individuals can support Pharo via the Pharo Association:

- http://association.pharo.org

[Pharo-dev] [Pharo 7.0-dev] Build #447: 21101 Super tearDown need to be called as last message in tearDown of OpalCompiler tests

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #447 was: SUCCESS.

The Pull Request #729 was integrated: "21101 Super tearDown need to be called 
as last message in tearDown of OpalCompiler tests"
Pull request url: https://github.com/pharo-project/pharo/pull/729

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

Re: [Pharo-dev] Moving from mc to tonel?

[Peter Uhnák]

Hi Martin,

there are some pull requests regarding encoding, I finally have a bit more
time so I'll look into that in the coming days.

Peter

On Thu, Jan 25, 2018 at 3:57 AM, Martin Dias  wrote:

> Hi, any news or experiences on the migration tools? I'd try again on next
> days.
> Martín
>
> On Sat, Dec 16, 2017 at 5:06 AM, Stephane Ducasse  > wrote:
>
>> It would be great to be able to sanitize the files.
>> We should get a test about tonel misbehavior.
>>
>> Stef
>>
>> On Thu, Dec 14, 2017 at 3:11 PM, Henrik Sperre Johansen
>>  wrote:
>> > Stephan Eggermont-3 wrote
>> >> On 05-12-17 08:59, Peter Uhnák wrote:
>> >>>  > In my case, it turned out to be a non-UTF8 encoded character in one
>> >>> of the commit messages.
>> >>>
>> >>> I've ran into this problem in a sister project (tonel-migration), and
>> do
>> >>> not have a proper resolution yet. I was forcing everything to be
>> >>> unicode, so I need a better way to read and write encoded strings. :<
>> >>
>> >> To be exact, exactly none of the older commits will be UTF8 encoded.
>> For
>> >> most it doesn't matter as they are ASCII, but if we want to have a
>> >> change of converting older french or german code (or japanese), we need
>> >> support for what was done with WideString. That probably needs a look
>> in
>> >> the squeak mailing list archives.
>> >>
>> >> Stephan
>> >
>> > The mcz reader used to import the .bin file (which contained correctly
>> > serialized WideStrings), only falling back to reading the .st file if
>> .bin
>> > was not present, has this changed?
>> >
>> > Or do these tools explicitly ignore the .bin file and try to read the
>> .st
>> > file directly?
>> > If so, the MCDataStream class used to read .bin format still seems to
>> be in
>> > the image...
>> >
>> > One could also create a tool to check/convert all mcz in a repo as a
>> > preprocess;
>> > if .bin contents decode as WideString,
>> > check that .st starts with utf8 BOM,
>> > if not, convert.
>> >
>> > Cheers,
>> > Henry
>> >
>> >
>> >
>> > --
>> > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.ht
>> ml
>> >
>>
>>
>