Re: [Pharo-dev] Corrupt method source in Pharo 6.1 (stable)

[Bernhard Pieber]

Hi Sean,

Thanks for taking the time to try to confirm this. Did you use Pharo Launcher? 
I just tried it using get.pharo.org and don’t see the corruption. So it seems 
to be specific to Launcher somehow. :-/

Bernhard

> Am 06.12.2017 um 01:04 schrieb Sean P. DeNigris :
> 
> bpi wrote
>> Can anyone else confirm that?
> 
> It seems okay for me:
> 
>  
> 
> Image
> -
> Pharo6.0
> Latest update: #60524
> Unnamed
> 
> Virtual Machine
> ---
> ~/Documents/Pharo/vms/61-x86/Pharo.app/Contents/MacOS/Pharo
> CoInterpreter VMMaker.oscog-eem.2254 uuid:
> 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017
> StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid:
> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017
> VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
> Date: Thu Jul 20 12:42:21 2017 -0700 $ Plugins: 201707201942
> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
> 
> Mac OS X built on Jul 20 2017 21:45:23 UTC Compiler: 4.2.1 Compatible Apple
> LLVM 6.1.0 (clang-602.0.53)
> VMMaker versionString VM: 201707201942
> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Jul 20
> 12:42:21 2017 -0700 $ Plugins: 201707201942
> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
> CoInterpreter VMMaker.oscog-eem.2254 uuid:
> 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017
> StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid:
> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017
> 
> Operating System/Hardware
> -
> Mac OS 1013.1 intel
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 

Re: [Pharo-dev] Is Pharo spying on me?

[Tudor Girba]

Hi,

What exactly are we removing?

Cheers,
Doru


> On Dec 5, 2017, at 9:41 PM, Esteban Lorenzano  wrote:
> 
> but you are asked to share it, this is not collected automatically without 
> asking before.
> 
> anyway, we are removing that (if not removed yet) 
> 
>> On 5 Dec 2017, at 21:34, Sean Glazier  wrote:
>> 
>> Personally, I know of work places where this is not going to be allowed. I 
>> understand they need the data, but you need to be able to turn it off. A 
>> secure facility would not allow the transmission out in any case.
>> 
>>  
>> Kind Regards,
>>  
>> Sean Glazier
>>  
>> 
>> On Tue, Dec 5, 2017 at 2:45 PM, Juraj Kubelka  
>> wrote:
>> Check Privacy section in Settings Browser.
>> If you ever send anything, data are anonymized.
>> Developers use it to be able to evaluate their research (PhD) work. It is a 
>> requirement in the research field.
>> By sending the anonymized data, you help developers to understand how their 
>> tools are used.
>> In particular, I am aware of Spotter, Quality Assistant, GT tools, and 
>> Roassal.
>> 
>> Cheers,
>> Juraj
>> 
>> > On Dec 5, 2017, at 16:30, Bernhard Pieber  wrote:
>> >
>> > I just found a file named org.pharo.global-identifiers.ston in my 
>> > preferences folder. It contains a #secretUUID and a #computerUUID. :-( 
>> > What is this information used for? More importantly, how can I turn it off?
>> >
>> > Bernhard
>> 
>> 
>> 
> 

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

"Next time you see your life passing by, say 'hi' and get to know her."

Re: [Pharo-dev] Is Pharo spying on me?

[Tudor Girba]

Hi,

Indeed privacy is an important issue. When we introduced the collection of data 
in Spotter we made sure that:
- the collection of data is off by default
- you are asked explicitly to turn it on
- and, even when you send the data, you are sending technical tool data or at 
most, anonymized data.

In other words, we want people to send data, but they should be in control and 
sending data should always be an opt-in and as transparent as possible.

Right now, there is a central Privacy setting holder that is being used to 
guard the usage of the GTEventRecorder. To check that this is the case, take a 
look at the result of this query:
(SystemNavigation new allReferencesTo: GTEventRecorder binding) \ 
(SystemNavigation new allReferencesTo: Privacy binding)
==>
GtExamplesReleaseTest>>#testAllMissingInternalExamples
GTEventRecorderHelp class>>#client
GTEventRecorderTest>>#setUp
GTEventCollector>>#register

These are only test, help and registration methods, which are fine.

We should make a QA rule out of this.

In the future, we would like to work on a more obvious signal that data is 
being collected.

Cheers,
Doru



> On Dec 5, 2017, at 9:43 PM, Esteban Lorenzano  wrote:
> 
> anyway *no data is collected without asking first* 
> 
> I demanded that and if someone sneaked in without permission, I will be very 
> very upset.
> 
> Esteban
> 
>> On 5 Dec 2017, at 21:39, Juraj Kubelka  wrote:
>> 
>> I understand it. For that reason there are settings.
>> 
>> Cheers,
>> Juraj
>> 
>>> On Dec 5, 2017, at 17:34, Sean Glazier  wrote:
>>> 
>>> Personally, I know of work places where this is not going to be allowed. I 
>>> understand they need the data, but you need to be able to turn it off. A 
>>> secure facility would not allow the transmission out in any case.
>>> 
>>>  
>>> Kind Regards,
>>>  
>>> Sean Glazier
>>>  
>>> 
>>> On Tue, Dec 5, 2017 at 2:45 PM, Juraj Kubelka  
>>> wrote:
>>> Check Privacy section in Settings Browser.
>>> If you ever send anything, data are anonymized.
>>> Developers use it to be able to evaluate their research (PhD) work. It is a 
>>> requirement in the research field.
>>> By sending the anonymized data, you help developers to understand how their 
>>> tools are used.
>>> In particular, I am aware of Spotter, Quality Assistant, GT tools, and 
>>> Roassal.
>>> 
>>> Cheers,
>>> Juraj
>>> 
>>> > On Dec 5, 2017, at 16:30, Bernhard Pieber  wrote:
>>> >
>>> > I just found a file named org.pharo.global-identifiers.ston in my 
>>> > preferences folder. It contains a #secretUUID and a #computerUUID. :-( 
>>> > What is this information used for? More importantly, how can I turn it 
>>> > off?
>>> >
>>> > Bernhard
>>> 
>>> 
>>> 
>> 
> 

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

"Value is always contextual."

Re: [Pharo-dev] Corrupt method source in Pharo 6.1 (stable)

[Sean P. DeNigris]

bpi wrote
> Can anyone else confirm that?

It seems okay for me:

 

Image
-
Pharo6.0
Latest update: #60524
Unnamed

Virtual Machine
---
~/Documents/Pharo/vms/61-x86/Pharo.app/Contents/MacOS/Pharo
CoInterpreter VMMaker.oscog-eem.2254 uuid:
4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017
StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid:
2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017
VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Date: Thu Jul 20 12:42:21 2017 -0700 $ Plugins: 201707201942
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $

Mac OS X built on Jul 20 2017 21:45:23 UTC Compiler: 4.2.1 Compatible Apple
LLVM 6.1.0 (clang-602.0.53)
VMMaker versionString VM: 201707201942
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Jul 20
12:42:21 2017 -0700 $ Plugins: 201707201942
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
CoInterpreter VMMaker.oscog-eem.2254 uuid:
4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017
StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid:
2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017

Operating System/Hardware
-
Mac OS 1013.1 intel



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

Re: [Pharo-dev] Is Pharo spying on me?

[Pavel Krivanek]

2017-12-05 20:30 GMT+01:00 Bernhard Pieber :

> I just found a file named org.pharo.global-identifiers.ston in my
> preferences folder. It contains a #secretUUID and a #computerUUID. :-( What
> is this information used for? More importantly, how can I turn it off?
>

There is nothing evil on it. It is used for resolving if the preferences
should be reloaded. See SystemSettingsPersistence
class>>#resumeSystemSettings

-- Pavel


>
> Bernhard
>

Re: [Pharo-dev] Is Pharo spying on me?

[Esteban Lorenzano]

anyway *no data is collected without asking first* 

I demanded that and if someone sneaked in without permission, I will be very 
very upset.

Esteban

> On 5 Dec 2017, at 21:39, Juraj Kubelka  wrote:
> 
> I understand it. For that reason there are settings.
> 
> Cheers,
> Juraj
> 
>> On Dec 5, 2017, at 17:34, Sean Glazier > > wrote:
>> 
>> Personally, I know of work places where this is not going to be allowed. I 
>> understand they need the data, but you need to be able to turn it off. A 
>> secure facility would not allow the transmission out in any case.
>> 
>>  
>> Kind Regards,
>>  
>> Sean Glazier
>>  
>> 
>> On Tue, Dec 5, 2017 at 2:45 PM, Juraj Kubelka > > wrote:
>> Check Privacy section in Settings Browser.
>> If you ever send anything, data are anonymized.
>> Developers use it to be able to evaluate their research (PhD) work. It is a 
>> requirement in the research field.
>> By sending the anonymized data, you help developers to understand how their 
>> tools are used.
>> In particular, I am aware of Spotter, Quality Assistant, GT tools, and 
>> Roassal.
>> 
>> Cheers,
>> Juraj
>> 
>> > On Dec 5, 2017, at 16:30, Bernhard Pieber > > > wrote:
>> >
>> > I just found a file named org.pharo.global-identifiers.ston in my 
>> > preferences folder. It contains a #secretUUID and a #computerUUID. :-( 
>> > What is this information used for? More importantly, how can I turn it off?
>> >
>> > Bernhard
>> 
>> 
>> 
> 

Re: [Pharo-dev] Is Pharo spying on me?

[Esteban Lorenzano]

but you are asked to share it, this is not collected automatically without 
asking before.

anyway, we are removing that (if not removed yet) 

> On 5 Dec 2017, at 21:34, Sean Glazier  wrote:
> 
> Personally, I know of work places where this is not going to be allowed. I 
> understand they need the data, but you need to be able to turn it off. A 
> secure facility would not allow the transmission out in any case.
> 
>  
> Kind Regards,
>  
> Sean Glazier
>  
> 
> On Tue, Dec 5, 2017 at 2:45 PM, Juraj Kubelka  > wrote:
> Check Privacy section in Settings Browser.
> If you ever send anything, data are anonymized.
> Developers use it to be able to evaluate their research (PhD) work. It is a 
> requirement in the research field.
> By sending the anonymized data, you help developers to understand how their 
> tools are used.
> In particular, I am aware of Spotter, Quality Assistant, GT tools, and 
> Roassal.
> 
> Cheers,
> Juraj
> 
> > On Dec 5, 2017, at 16:30, Bernhard Pieber  > > wrote:
> >
> > I just found a file named org.pharo.global-identifiers.ston in my 
> > preferences folder. It contains a #secretUUID and a #computerUUID. :-( What 
> > is this information used for? More importantly, how can I turn it off?
> >
> > Bernhard
> 
> 
> 

Re: [Pharo-dev] Is Pharo spying on me?

[Juraj Kubelka]

I understand it. For that reason there are settings.

Cheers,
Juraj

> On Dec 5, 2017, at 17:34, Sean Glazier  wrote:
> 
> Personally, I know of work places where this is not going to be allowed. I 
> understand they need the data, but you need to be able to turn it off. A 
> secure facility would not allow the transmission out in any case.
> 
>  
> Kind Regards,
>  
> Sean Glazier
>  
> 
> On Tue, Dec 5, 2017 at 2:45 PM, Juraj Kubelka  > wrote:
> Check Privacy section in Settings Browser.
> If you ever send anything, data are anonymized.
> Developers use it to be able to evaluate their research (PhD) work. It is a 
> requirement in the research field.
> By sending the anonymized data, you help developers to understand how their 
> tools are used.
> In particular, I am aware of Spotter, Quality Assistant, GT tools, and 
> Roassal.
> 
> Cheers,
> Juraj
> 
> > On Dec 5, 2017, at 16:30, Bernhard Pieber  > > wrote:
> >
> > I just found a file named org.pharo.global-identifiers.ston in my 
> > preferences folder. It contains a #secretUUID and a #computerUUID. :-( What 
> > is this information used for? More importantly, how can I turn it off?
> >
> > Bernhard
> 
> 
> 

Re: [Pharo-dev] Is Pharo spying on me?

[Sean Glazier]

Personally, I know of work places where this is not going to be allowed. I
understand they need the data, but you need to be able to turn it off. A
secure facility would not allow the transmission out in any case.


Kind Regards,

Sean Glazier


On Tue, Dec 5, 2017 at 2:45 PM, Juraj Kubelka 
wrote:

> Check Privacy section in Settings Browser.
> If you ever send anything, data are anonymized.
> Developers use it to be able to evaluate their research (PhD) work. It is
> a requirement in the research field.
> By sending the anonymized data, you help developers to understand how
> their tools are used.
> In particular, I am aware of Spotter, Quality Assistant, GT tools, and
> Roassal.
>
> Cheers,
> Juraj
>
> > On Dec 5, 2017, at 16:30, Bernhard Pieber  wrote:
> >
> > I just found a file named org.pharo.global-identifiers.ston in my
> preferences folder. It contains a #secretUUID and a #computerUUID. :-( What
> is this information used for? More importantly, how can I turn it off?
> >
> > Bernhard
>
>
>

[Pharo-dev] Corrupt method source in Pharo 6.1 (stable)

[Bernhard Pieber]

I did the following in Pharo Launcher:
1. Select Official distributions > Pharo 6.1 (stable)
2. Click Create Image
3. Launch created image
4. Browse GLMAccumulator
5. Click on any method, e.g. activeEntity => method source is corrupt, e.g. mp: 
‚tg 2/2/2010 22:03'

I tried it twice, also with the Pharo 6.0 > latest image.

Can anyone else confirm that?

Bernhard

Re: [Pharo-dev] Is Pharo spying on me?

[Juraj Kubelka]

Check Privacy section in Settings Browser.
If you ever send anything, data are anonymized.
Developers use it to be able to evaluate their research (PhD) work. It is a 
requirement in the research field.
By sending the anonymized data, you help developers to understand how their 
tools are used.
In particular, I am aware of Spotter, Quality Assistant, GT tools, and Roassal.

Cheers,
Juraj

> On Dec 5, 2017, at 16:30, Bernhard Pieber  wrote:
> 
> I just found a file named org.pharo.global-identifiers.ston in my preferences 
> folder. It contains a #secretUUID and a #computerUUID. :-( What is this 
> information used for? More importantly, how can I turn it off?
> 
> Bernhard

[Pharo-dev] Is Pharo spying on me?

[Bernhard Pieber]

I just found a file named org.pharo.global-identifiers.ston in my preferences 
folder. It contains a #secretUUID and a #computerUUID. :-( What is this 
information used for? More importantly, how can I turn it off?

Bernhard

[Pharo-dev] Crash Dump - GT loaded into 6.1

[Sean P. DeNigris]

Let me know if you need any other info…

Image
-
Pharo6.0
Latest update: #60523
Unnamed

Virtual Machine
---
~/Documents/Pharo/vms/61-x86/Pharo.app/Contents/MacOS/Pharo
CoInterpreter VMMaker.oscog-eem.2254 uuid:
4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017
StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid:
2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017
VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Date: Thu Jul 20 12:42:21 2017 -0700 $ Plugins: 201707201942
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $

Mac OS X built on Jul 20 2017 21:45:23 UTC Compiler: 4.2.1 Compatible Apple
LLVM 6.1.0 (clang-602.0.53)
VMMaker versionString VM: 201707201942
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Jul 20
12:42:21 2017 -0700 $ Plugins: 201707201942
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
CoInterpreter VMMaker.oscog-eem.2254 uuid:
4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017
StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid:
2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017

*Here's the top part of the dmp:*

Bus error

VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Date: Thu Jul 20 12:42:21 2017 -0700 $
Plugins: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
$

C stack backtrace & registers:
eax 0x6b50fd00 ebx 0x6dd03c90 ecx 0x88bb edx 0x012f39a0
edi 0x6dd03c30 esi 0x6dd03c30 ebp 0xbff89a88 esp 0xbff89a7c
eip 0x88bb
0   ??? 0x88bb 0x0 + 2293956608
1   Pharo   0x000c5460 reportStackState + 819
2   Pharo   0x000c57e6 sigsegv + 163
3   libsystem_platform.dylib0xa778202b _sigtramp + 43
4   ??? 0x 0x0 + 4294967295
5   libMoz2D.dylib  0x1394b9d3 _ZN12PLDHashTableD1Ev +
67
6   libMoz2D.dylib  0x13b9e492
_ZN21nsLanguageAtomService7ReleaseEv + 82
7   libMoz2D.dylib  0x138dd879
_ZN19gfxPlatformFontListD2Ev + 377
8   libMoz2D.dylib  0x13902881
_ZN22gfxMacPlatformFontListD0Ev + 17
9   libMoz2D.dylib  0x13877839
_ZN11gfxPlatform8ShutdownEv + 73
10  Pharo   0x000fb3d2 primitiveCalloutWithArgs
+ 1748
11  Pharo   0x00055357 executeNewMethod + 144
12  Pharo   0x00056187 ceSendsupertonumArgs +
1017
13  ??? 0x061310a3 0x0 + 101912739
14  Pharo   0x000403ab interpret + 646
15  Pharo   0x000c69d9 -[sqSqueakMainApplication
runSqueak] + 476
16  Foundation  0x953897ec __NSFirePerformWithOrder
+ 432
17  CoreFoundation  0x9392a216
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 22
18  CoreFoundation  0x9392a132 __CFRunLoopDoObservers +
498
19  CoreFoundation  0x9390d5ed __CFRunLoopRun + 1661
20  CoreFoundation  0x9390cc41 CFRunLoopRunSpecific +
641
21  CoreFoundation  0x9390c9aa CFRunLoopRunInMode + 122
22  HIToolbox   0x92f0dd3b RunCurrentEventLoopInMode
+ 321
23  HIToolbox   0x92f0d91f ReceiveNextEventCommon +
454
24  HIToolbox   0x92f0d73b
_BlockUntilNextEventMatchingListInModeWithFilter + 71
25  AppKit  0x9136538d _DPSNextEvent + 2101
26  AppKit  0x91ad6c74 -[NSApplication(NSEvent)
_nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2859
27  AppKit  0x91ad6141 -[NSApplication(NSEvent)
nextEventMatchingMask:untilDate:inMode:dequeue:] + 134
28  AppKit  0x9135a2e1 -[NSApplication run] +
763
29  AppKit  0x9132c2f2 NSApplicationMain + 1228
30  libdyld.dylib   0xa7502711 start + 1


Smalltalk stack dump:
0xbffa09e4 M MozServices class>primShutdownPlatform 0xb45b538: a(n)
MozServices class
0xbffa0a10 I FFICalloutAPI>function:module: 0x642b5a0: a(n) FFICalloutAPI
0xbffa0a38 I MozServices class(Object)>ffiCall: 0xb45b538: a(n) MozServices
class
0xbffa0a5c I MozServices class>primShutdownPlatform 0xb45b538: a(n)
MozServices class
0xbffa0a74 M [] in MozServices class>stop 0xb45b538: a(n) MozServices class
0xbffa0a94 M BlockClosure>ensure: 0x641e930: a(n) BlockClosure
0xbffa0ab8 I MozServices class>stop 0xb45b538: a(n) MozServices class
0xbffa0ad8 I MozServices class>shutDown: 0xb45b538: a(n) MozServices class
0xbffa0af4 M ClassSessionHandler>shutdown: 0xb7c7dc8: a(n)
ClassSessionHandler
0xbffa0b14 M [] in WorkingSession>runShutdown: 0x8c5c0f8: a(n)
WorkingSession
0xbffa0b38 M [] in WorkingSession>runList:do: 0x8c5c0f8: a(n) WorkingSession
0xbffa0b50 M BlockClosure>on:do: 0x641e770: 

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

[Stephane Ducasse]

We tried

| parser doc visitor |
parser := XMLDOMParser new
on: self xmlContents;
preservesIgnorableWhitespace: false.
doc := parser parseDocument.

but we still have the empty nodes around.

Stef


On Tue, Dec 5, 2017 at 2:29 PM, Stephane Ducasse
 wrote:
> )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

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

[Stephane Ducasse]

)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] Moving from mc to tonel?

[Alistair Grant]

Hi Peter,

On 5 December 2017 at 11:55, Peter Uhnák  wrote:
>> Would you be open to a PR that incorporates Sven's changes suggested
>> above?
>
> Certainly. One thing to keep in mind is that I had to modify
> MemoryStore/MemoryHandle so it can process unicode at all, but it also
> forces everything to be unicode.

This is probably a good thing.  The fast-import documentation says
that it is strict about character encoding and only accepts UTF-8.

I'll let you know when the PRs are ready.

Thanks,
Alistair


>> I hate having to deal with string encoding, and know as little as
>> possible. :-)
>
> Apparently me taking this approach resulted in the current situation. :-D
>
> Peter
>
> On Tue, Dec 5, 2017 at 10:27 AM, Alistair Grant 
> wrote:
>>
>> On Tue, Dec 05, 2017 at 08:56:53AM +0100, Sven Van Caekenberghe wrote:
>> >
>> > > On 5 Dec 2017, at 08:34, Alistair Grant  wrote:
>> > >
>> > > On 5 December 2017 at 03:41, Martin Dias  wrote:
>> > >> I suspect it's related to the large number of commits in my repo. I
>> > >> made
>> > >> some tweaks and succeeded to create the fast-import file. But I get:
>> > >>
>> > >> fatal: Unsupported command: .
>> > >> fast-import: dumping crash report to .git/fast_import_crash_10301
>> > >>
>> > >> Do you recognize this error?
>> > >> I will check my changes tweaking the git-migration tool to see if I
>> > >> modified
>> > >> some behavior my mistake...
>> > >
>> > > I had the same error just last night.
>> > >
>> > > In my case, it turned out to be a non-UTF8 encoded character in one of
>> > > the commit messages.
>> > >
>> > > I tracked it down by looking at the crash report and searching for a
>> > > nearby command.  I've deleted the crash reports now, but I think it
>> > > was the number associated with a mark command that got me near the
>> > > problem character in the fast-import file.
>> > >
>> > > I also modified the code to halt whenever it found a non-UTF8
>> > > character.  I'm sure there are better ways to do this, but:
>> > >
>> > >
>> > > GitMigrationCommitInfo>>inlineDataFor: aString
>> > >
>> > >| theString |
>> > >theString := aString.
>> > >"Ensure the message has valid UTF-8 encoding (this will raise an
>> > > error if it doesn't)"
>> > >[ (ZnCharacterEncoder newForEncoding: 'utf8') decodeBytes: aString
>> > > asByteArray ]
>> > >on: Error
>> > >do: [ :ex | self halt: 'Illegal string encoding'.
>> > >theString := aString select: [ :each | each asciiValue
>> > > between: 32 and: 128 ] ].
>> > >^ 'data ' , theString size asString , String cr , (theString
>> > > ifEmpty: [ '' ] ifNotEmpty: [ theString , String cr ])
>> >
>> > There is also ByteArray>>#utf8Decoded (as well as
>> > String>>#utf8Encoded), both using the newer ZnCharacterEncoders. So
>> > you could write it shorter as:
>> >
>> >   aString asByteArray utf8Decoded
>> >
>> > Instead of Error you could use the more intention revealing
>> > ZnCharacterEncodingError.
>>
>> I agree, this was a hack to get me past the immediate issue and see if
>> I could get the migration to work.
>>
>>
>> > Apart from that, and I known you did not create this mess, encoding a
>> > String into a String, although it can be done, is so wrong. You encode
>> > a String (a collection of Characters, of Unicode code points) into a
>> > ByteArray and you decode a ByteArray into a String.
>> >
>> > Sending #asByteArray to a String in almost always wrong, as is sending
>> > #asString to a ByteArray. These are implicit conversions (null
>> > conversions, like ZnNullEncoder) that only work for pure ASCII or
>> > Latin1 (iso-8859-1), but not for the much richer set of Characters
>> > that Pharo supports. So these will eventually fail, one day, in a
>> > country far away.
>>
>> I hate having to deal with string encoding, and know as little as
>> possible. :-)
>>
>>
>>
>> On Tue, Dec 05, 2017 at 08:59:34AM +0100, 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. :<
>>
>> I think this is always going to be a tricky problem since the file may
>> simply be corrupt, and the resolution won't always be the same.  In my
>> case I was happy to simply remove the offending characters.
>>
>> I do think it would be nice if the migration tool at least stopped and
>> warned the user that the input is invalid.
>>
>> Would you be open to a PR that incorporates Sven's changes suggested
>> above?
>>
>>
>>
>> On Tue, Dec 05, 2017 at 09:05:24AM +0100, Sven Van Caekenberghe wrote:
>> >
>> > Maybe ZnCharacterEncoder class>>#detectEncoding: can help, although it
>> > is far from perfect.
>>
>> In this particular 

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

[Peter Uhnák]

> Would you be open to a PR that incorporates Sven's changes suggested
above?

Certainly. One thing to keep in mind is that I had to modify
MemoryStore/MemoryHandle so it can process unicode at all, but it also
forces everything to be unicode.

> I hate having to deal with string encoding, and know as little as possible.
:-)

Apparently me taking this approach resulted in the current situation. :-D

Peter

On Tue, Dec 5, 2017 at 10:27 AM, Alistair Grant 
wrote:

> On Tue, Dec 05, 2017 at 08:56:53AM +0100, Sven Van Caekenberghe wrote:
> >
> > > On 5 Dec 2017, at 08:34, Alistair Grant  wrote:
> > >
> > > On 5 December 2017 at 03:41, Martin Dias  wrote:
> > >> I suspect it's related to the large number of commits in my repo. I
> made
> > >> some tweaks and succeeded to create the fast-import file. But I get:
> > >>
> > >> fatal: Unsupported command: .
> > >> fast-import: dumping crash report to .git/fast_import_crash_10301
> > >>
> > >> Do you recognize this error?
> > >> I will check my changes tweaking the git-migration tool to see if I
> modified
> > >> some behavior my mistake...
> > >
> > > I had the same error just last night.
> > >
> > > In my case, it turned out to be a non-UTF8 encoded character in one of
> > > the commit messages.
> > >
> > > I tracked it down by looking at the crash report and searching for a
> > > nearby command.  I've deleted the crash reports now, but I think it
> > > was the number associated with a mark command that got me near the
> > > problem character in the fast-import file.
> > >
> > > I also modified the code to halt whenever it found a non-UTF8
> > > character.  I'm sure there are better ways to do this, but:
> > >
> > >
> > > GitMigrationCommitInfo>>inlineDataFor: aString
> > >
> > >| theString |
> > >theString := aString.
> > >"Ensure the message has valid UTF-8 encoding (this will raise an
> > > error if it doesn't)"
> > >[ (ZnCharacterEncoder newForEncoding: 'utf8') decodeBytes: aString
> > > asByteArray ]
> > >on: Error
> > >do: [ :ex | self halt: 'Illegal string encoding'.
> > >theString := aString select: [ :each | each asciiValue
> > > between: 32 and: 128 ] ].
> > >^ 'data ' , theString size asString , String cr , (theString
> > > ifEmpty: [ '' ] ifNotEmpty: [ theString , String cr ])
> >
> > There is also ByteArray>>#utf8Decoded (as well as
> > String>>#utf8Encoded), both using the newer ZnCharacterEncoders. So
> > you could write it shorter as:
> >
> >   aString asByteArray utf8Decoded
> >
> > Instead of Error you could use the more intention revealing
> ZnCharacterEncodingError.
>
> I agree, this was a hack to get me past the immediate issue and see if
> I could get the migration to work.
>
>
> > Apart from that, and I known you did not create this mess, encoding a
> > String into a String, although it can be done, is so wrong. You encode
> > a String (a collection of Characters, of Unicode code points) into a
> > ByteArray and you decode a ByteArray into a String.
> >
> > Sending #asByteArray to a String in almost always wrong, as is sending
> > #asString to a ByteArray. These are implicit conversions (null
> > conversions, like ZnNullEncoder) that only work for pure ASCII or
> > Latin1 (iso-8859-1), but not for the much richer set of Characters
> > that Pharo supports. So these will eventually fail, one day, in a
> > country far away.
>
> I hate having to deal with string encoding, and know as little as
> possible. :-)
>
>
>
> On Tue, Dec 05, 2017 at 08:59:34AM +0100, 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. :<
>
> I think this is always going to be a tricky problem since the file may
> simply be corrupt, and the resolution won't always be the same.  In my
> case I was happy to simply remove the offending characters.
>
> I do think it would be nice if the migration tool at least stopped and
> warned the user that the input is invalid.
>
> Would you be open to a PR that incorporates Sven's changes suggested
> above?
>
>
>
> On Tue, Dec 05, 2017 at 09:05:24AM +0100, Sven Van Caekenberghe wrote:
> >
> > Maybe ZnCharacterEncoder class>>#detectEncoding: can help, although it
> > is far from perfect.
>
> In this particular case I think it is better to try decoding with UTF8,
> since #detectEncoding: isn't completely reliable and we just want to
> know if it isn't valid UTF8.
>
>
> Cheers,
> Alistair
>
>

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

[Alistair Grant]

On Tue, Dec 05, 2017 at 08:56:53AM +0100, Sven Van Caekenberghe wrote:
> 
> > On 5 Dec 2017, at 08:34, Alistair Grant  wrote:
> > 
> > On 5 December 2017 at 03:41, Martin Dias  wrote:
> >> I suspect it's related to the large number of commits in my repo. I made
> >> some tweaks and succeeded to create the fast-import file. But I get:
> >> 
> >> fatal: Unsupported command: .
> >> fast-import: dumping crash report to .git/fast_import_crash_10301
> >> 
> >> Do you recognize this error?
> >> I will check my changes tweaking the git-migration tool to see if I 
> >> modified
> >> some behavior my mistake...
> > 
> > I had the same error just last night.
> > 
> > In my case, it turned out to be a non-UTF8 encoded character in one of
> > the commit messages.
> > 
> > I tracked it down by looking at the crash report and searching for a
> > nearby command.  I've deleted the crash reports now, but I think it
> > was the number associated with a mark command that got me near the
> > problem character in the fast-import file.
> > 
> > I also modified the code to halt whenever it found a non-UTF8
> > character.  I'm sure there are better ways to do this, but:
> > 
> > 
> > GitMigrationCommitInfo>>inlineDataFor: aString
> > 
> >| theString |
> >theString := aString.
> >"Ensure the message has valid UTF-8 encoding (this will raise an
> > error if it doesn't)"
> >[ (ZnCharacterEncoder newForEncoding: 'utf8') decodeBytes: aString
> > asByteArray ]
> >on: Error
> >do: [ :ex | self halt: 'Illegal string encoding'.
> >theString := aString select: [ :each | each asciiValue
> > between: 32 and: 128 ] ].
> >^ 'data ' , theString size asString , String cr , (theString
> > ifEmpty: [ '' ] ifNotEmpty: [ theString , String cr ])
> 
> There is also ByteArray>>#utf8Decoded (as well as 
> String>>#utf8Encoded), both using the newer ZnCharacterEncoders. So 
> you could write it shorter as:
> 
>   aString asByteArray utf8Decoded
> 
> Instead of Error you could use the more intention revealing 
> ZnCharacterEncodingError.

I agree, this was a hack to get me past the immediate issue and see if 
I could get the migration to work.


> Apart from that, and I known you did not create this mess, encoding a 
> String into a String, although it can be done, is so wrong. You encode 
> a String (a collection of Characters, of Unicode code points) into a 
> ByteArray and you decode a ByteArray into a String.
> 
> Sending #asByteArray to a String in almost always wrong, as is sending 
> #asString to a ByteArray. These are implicit conversions (null 
> conversions, like ZnNullEncoder) that only work for pure ASCII or 
> Latin1 (iso-8859-1), but not for the much richer set of Characters 
> that Pharo supports. So these will eventually fail, one day, in a 
> country far away.

I hate having to deal with string encoding, and know as little as 
possible. :-)



On Tue, Dec 05, 2017 at 08:59:34AM +0100, 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. :<

I think this is always going to be a tricky problem since the file may 
simply be corrupt, and the resolution won't always be the same.  In my 
case I was happy to simply remove the offending characters.

I do think it would be nice if the migration tool at least stopped and 
warned the user that the input is invalid.

Would you be open to a PR that incorporates Sven's changes suggested 
above?



On Tue, Dec 05, 2017 at 09:05:24AM +0100, Sven Van Caekenberghe wrote:
> 
> Maybe ZnCharacterEncoder class>>#detectEncoding: can help, although it 
> is far from perfect.

In this particular case I think it is better to try decoding with UTF8, 
since #detectEncoding: isn't completely reliable and we just want to 
know if it isn't valid UTF8.


Cheers,
Alistair

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

[Cyril Ferlicot]

On mar. 5 déc. 2017 at 09:20, Nicolai Hess  wrote:

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


Hi!

Pavel found it comes from this PR yesterday:
https://github.com/pharo-project/pharo/pull/553

Now we need to find what is the problem, probably locals initialization.


> nicolai
>
> --
Cyril Ferlicot
https://ferlicot.fr

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

[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] [Moose-dev] feenk log

[Peter Uhnák]

Great work guys!

Even though I don't have much time to work with Bloc yet, every time I play
with it, I find it really enjoyable. :)

Also +1 for draggable elements, another thing to tick of my "must have"
list. :)

Peter

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

[Sven Van Caekenberghe]

> On 5 Dec 2017, at 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. :<

Maybe ZnCharacterEncoder class>>#detectEncoding: can help, although it is far 
from perfect.

> On Tue, Dec 5, 2017 at 8:56 AM, Sven Van Caekenberghe  wrote:
> 
> 
> > On 5 Dec 2017, at 08:34, Alistair Grant  wrote:
> >
> > On 5 December 2017 at 03:41, Martin Dias  wrote:
> >> I suspect it's related to the large number of commits in my repo. I made
> >> some tweaks and succeeded to create the fast-import file. But I get:
> >>
> >> fatal: Unsupported command: .
> >> fast-import: dumping crash report to .git/fast_import_crash_10301
> >>
> >> Do you recognize this error?
> >> I will check my changes tweaking the git-migration tool to see if I 
> >> modified
> >> some behavior my mistake...
> >
> > I had the same error just last night.
> >
> > In my case, it turned out to be a non-UTF8 encoded character in one of
> > the commit messages.
> >
> > I tracked it down by looking at the crash report and searching for a
> > nearby command.  I've deleted the crash reports now, but I think it
> > was the number associated with a mark command that got me near the
> > problem character in the fast-import file.
> >
> > I also modified the code to halt whenever it found a non-UTF8
> > character.  I'm sure there are better ways to do this, but:
> >
> >
> > GitMigrationCommitInfo>>inlineDataFor: aString
> >
> >| theString |
> >theString := aString.
> >"Ensure the message has valid UTF-8 encoding (this will raise an
> > error if it doesn't)"
> >[ (ZnCharacterEncoder newForEncoding: 'utf8') decodeBytes: aString
> > asByteArray ]
> >on: Error
> >do: [ :ex | self halt: 'Illegal string encoding'.
> >theString := aString select: [ :each | each asciiValue
> > between: 32 and: 128 ] ].
> >^ 'data ' , theString size asString , String cr , (theString
> > ifEmpty: [ '' ] ifNotEmpty: [ theString , String cr ])
> 
> There is also ByteArray>>#utf8Decoded (as well as String>>#utf8Encoded), both 
> using the newer ZnCharacterEncoders. So you could write it shorter as:
> 
>   aString asByteArray utf8Decoded
> 
> Instead of Error you could use the more intention revealing 
> ZnCharacterEncodingError.
> 
> Apart from that, and I known you did not create this mess, encoding a String 
> into a String, although it can be done, is so wrong. You encode a String (a 
> collection of Characters, of Unicode code points) into a ByteArray and you 
> decode a ByteArray into a String.
> 
> Sending #asByteArray to a String in almost always wrong, as is sending 
> #asString to a ByteArray. These are implicit conversions (null conversions, 
> like ZnNullEncoder) that only work for pure ASCII or Latin1 (iso-8859-1), but 
> not for the much richer set of Characters that Pharo supports. So these will 
> eventually fail, one day, in a country far away.
> 
> > Cheers,
> > Alistair
> >
> 
> 
> 

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

[Peter Uhnák]

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

On Tue, Dec 5, 2017 at 8:56 AM, Sven Van Caekenberghe  wrote:

>
>
> > On 5 Dec 2017, at 08:34, Alistair Grant  wrote:
> >
> > On 5 December 2017 at 03:41, Martin Dias  wrote:
> >> I suspect it's related to the large number of commits in my repo. I made
> >> some tweaks and succeeded to create the fast-import file. But I get:
> >>
> >> fatal: Unsupported command: .
> >> fast-import: dumping crash report to .git/fast_import_crash_10301
> >>
> >> Do you recognize this error?
> >> I will check my changes tweaking the git-migration tool to see if I
> modified
> >> some behavior my mistake...
> >
> > I had the same error just last night.
> >
> > In my case, it turned out to be a non-UTF8 encoded character in one of
> > the commit messages.
> >
> > I tracked it down by looking at the crash report and searching for a
> > nearby command.  I've deleted the crash reports now, but I think it
> > was the number associated with a mark command that got me near the
> > problem character in the fast-import file.
> >
> > I also modified the code to halt whenever it found a non-UTF8
> > character.  I'm sure there are better ways to do this, but:
> >
> >
> > GitMigrationCommitInfo>>inlineDataFor: aString
> >
> >| theString |
> >theString := aString.
> >"Ensure the message has valid UTF-8 encoding (this will raise an
> > error if it doesn't)"
> >[ (ZnCharacterEncoder newForEncoding: 'utf8') decodeBytes: aString
> > asByteArray ]
> >on: Error
> >do: [ :ex | self halt: 'Illegal string encoding'.
> >theString := aString select: [ :each | each asciiValue
> > between: 32 and: 128 ] ].
> >^ 'data ' , theString size asString , String cr , (theString
> > ifEmpty: [ '' ] ifNotEmpty: [ theString , String cr ])
>
> There is also ByteArray>>#utf8Decoded (as well as String>>#utf8Encoded),
> both using the newer ZnCharacterEncoders. So you could write it shorter as:
>
>   aString asByteArray utf8Decoded
>
> Instead of Error you could use the more intention revealing
> ZnCharacterEncodingError.
>
> Apart from that, and I known you did not create this mess, encoding a
> String into a String, although it can be done, is so wrong. You encode a
> String (a collection of Characters, of Unicode code points) into a
> ByteArray and you decode a ByteArray into a String.
>
> Sending #asByteArray to a String in almost always wrong, as is sending
> #asString to a ByteArray. These are implicit conversions (null conversions,
> like ZnNullEncoder) that only work for pure ASCII or Latin1 (iso-8859-1),
> but not for the much richer set of Characters that Pharo supports. So these
> will eventually fail, one day, in a country far away.
>
> > Cheers,
> > Alistair
> >
>
>
>