Smalltalk › Pharo › Pharo Smalltalk Developers

NativeBoost String Handling Bug?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

21 messages Options

Sean P. DeNigris

NativeBoost String Handling Bug?

Administrator

I'm tearing my hair out wrapping FMOD! I finally isolated the Mac VM-crashing bug (works in Windows) to:

The reason I suspect NB is that I made a simple Xcode C project which (I think) does the exact same thing, which works perfectly. I uploaded it to https://github.com/seandenigris/FMODExample .
To use it, just change SOUND_FILE_PATH in main.c to the location of the included "train whistle.mp3" file

From Pharo, however, it only works if the path to the mp3 is:
- *exactly* "/Volumes/NO NAME/Smalltalk/Working Images/Salty Dog/Sounds/train whistle.mp3". No other combination seems to work on my machine - even direct parents and subdirectories of that one! WTH!!
- or apparently a path without spaces

The thing that has me scratching my head is that even with spaces it works from Xcode!

To see the error from Pharo:

1. Gofer it
smalltalkhubUser: 'SeanDeNigris' project: 'FMOD';
package: 'FMOD';
load.

2. Copy the "FMOD Programmers API" folder from the C Sample into the image folder.

3. FmodLibrary exampleFmodStylePlaying: '/path/to/train whistle.mp3'.

I'd reaaaally appreciate Igor or another NB guru (if there is such a thing, lol) to take a look. I've spent days chasing this down, and I'm out of ideas... Thanks.

Cheers,
Sean

Igor Stasenko

Re: NativeBoost String Handling Bug?

On 2 December 2013 22:31, Sean P. DeNigris <[hidden email]> wrote:

I'm tearing my hair out wrapping FMOD! I finally isolated the Mac VM-crashing
bug (works in Windows) to:

The reason I suspect NB is that I made a simple Xcode C project which (I
think) does the exact same thing, which works perfectly. I uploaded it to
https://github.com/seandenigris/FMODExample .
To use it, just change SOUND_FILE_PATH in main.c to the location of the
included "train whistle.mp3" file

From Pharo, however, it only works if the path to the mp3 is:
- *exactly* "/Volumes/NO NAME/Smalltalk/Working Images/Salty
Dog/Sounds/train whistle.mp3". No other combination seems to work on my
machine - even direct parents and subdirectories of that one! WTH!!
- or apparently a path without spaces

sound really as some bug.. and similar to system() call.

my versions is:
- it could be that strings are expected to be 16-byte aligned
- that there's some bug with converting to null-terminated C string

The thing that has me scratching my head is that even with spaces it works
from Xcode!

To see the error from Pharo:

1. Gofer it
smalltalkhubUser: 'SeanDeNigris' project: 'FMOD';
package: 'FMOD';
load.

2. Copy the "FMOD Programmers API" folder from the C Sample into the image
folder.

3. FmodLibrary exampleFmodStylePlaying: '/path/to/train whistle.mp3'.

I'd reaaaally appreciate Igor or another NB guru (if there is such a thing,
lol) to take a look. I've spent days chasing this down, and I'm out of
ideas... Thanks.

-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

--
Best regards,
Igor Stasenko.

Sean P. DeNigris

Re: NativeBoost String Handling Bug?

Administrator

sound really as some bug.. and similar to system() call.
my versions is:
- it could be that strings are expected to be 16-byte aligned
- that there's some bug with converting to null-terminated C string

Great! It's be nice to get this and system calls working in one shot... how do we proceed? How do we test? I'm willing to help...

Cheers,
Sean

Igor Stasenko

Re: NativeBoost String Handling Bug?

On 3 December 2013 00:32, Sean P. DeNigris <[hidden email]> wrote:

sound really as some bug.. and similar to system() call.
my versions is:

- it could be that strings are expected to be 16-byte aligned

- that there's some bug with converting to null-terminated C string

Great! It's be nice to get this and system calls working in one shot... how do we proceed? How do we test? I'm willing to help...

if there some bug, it must be in NBExternalString

which responsible for marshalling strings.

try to change the alignment for the pointer and see how it goes in

reserveStackBytes: numBytesOrBlock andStoreAddrTo: aTemp

because right now it aligns the total space to reserve on stack

(amount to subtract from SP), but not SP itself

alignment should use powers of 2 , of course.

Cheers,
Sean

View this message in context: Re: NativeBoost String Handling Bug?

Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

--
Best regards,
Igor Stasenko.

Igor Stasenko

Re: NativeBoost String Handling Bug?

nevermind, i think i found the cause.

(system call now is working)

On 3 December 2013 02:08, Igor Stasenko <[hidden email]> wrote:

On 3 December 2013 00:32, Sean P. DeNigris <[hidden email]> wrote:

sound really as some bug.. and similar to system() call.
my versions is:

- it could be that strings are expected to be 16-byte aligned

- that there's some bug with converting to null-terminated C string

Great! It's be nice to get this and system calls working in one shot... how do we proceed? How do we test? I'm willing to help...

if there some bug, it must be in NBExternalString
which responsible for marshalling strings.
try to change the alignment for the pointer and see how it goes in

reserveStackBytes: numBytesOrBlock andStoreAddrTo: aTemp

because right now it aligns the total space to reserve on stack
(amount to subtract from SP), but not SP itself
alignment should use powers of 2 , of course.

Cheers,
Sean

View this message in context: Re: NativeBoost String Handling Bug?

Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

--
Best regards,
Igor Stasenko.

--
Best regards,
Igor Stasenko.

Sean P. DeNigris

Re: NativeBoost String Handling Bug?

Administrator

Hooray! How can I patch to see if it fixes my problem?

-------- Original message --------
From: "Igor Stasenko [via Smalltalk]" <[hidden email]>
Date: 12/02/2013 8:31 PM (GMT-05:00)
To: "Sean P. DeNigris" <[hidden email]>
Subject: Re: NativeBoost String Handling Bug?

nevermind, i think i found the cause.

(system call now is working)

On 3 December 2013 02:08, Igor Stasenko <[hidden email]> wrote:

On 3 December 2013 00:32, Sean P. DeNigris <[hidden email]> wrote:

sound really as some bug.. and similar to system() call.
my versions is:

- it could be that strings are expected to be 16-byte aligned

- that there's some bug with converting to null-terminated C string

Great! It's be nice to get this and system calls working in one shot... how do we proceed? How do we test? I'm willing to help...

if there some bug, it must be in NBExternalString
which responsible for marshalling strings.
try to change the alignment for the pointer and see how it goes in

reserveStackBytes: numBytesOrBlock andStoreAddrTo: aTemp

because right now it aligns the total space to reserve on stack
(amount to subtract from SP), but not SP itself
alignment should use powers of 2 , of course.

Cheers,
Sean

View this message in context: Re: NativeBoost String Handling Bug?

Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

--
Best regards,
Igor Stasenko.

--
Best regards,
Igor Stasenko.

If you reply to this email, your message will be added to the discussion below:

http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860p4726884.html

To unsubscribe from NativeBoost String Handling Bug?, click here.
NAML

Cheers,
Sean

Igor Stasenko

Re: NativeBoost String Handling Bug?

In reply to this post by Igor Stasenko

Name: NativeBoost-Core-IgorStasenko.140
Name: NativeBoost-Tests-IgorStasenko.75

try and see if it works for you (and try syscall too, if yes then i think we can finally close the bug entry).

P.S. thanks for being persistent on this one.

Igor Stasenko

Re: NativeBoost String Handling Bug?

In reply to this post by Sean P. DeNigris

On 3 December 2013 03:17, Sean P. DeNigris <[hidden email]> wrote:

Hooray! How can I patch to see if it fixes my problem?

just update your inbox. and see my other post :)

-------- Original message --------
From: "Igor Stasenko [via Smalltalk]" <[hidden email]>
Date: 12/02/2013 8:31 PM (GMT-05:00)
To: "Sean P. DeNigris" <[hidden email]>
Subject: Re: NativeBoost String Handling Bug?

nevermind, i think i found the cause.
(system call now is working)

On 3 December 2013 02:08, Igor Stasenko <[hidden email]> wrote:

On 3 December 2013 00:32, Sean P. DeNigris <[hidden email]> wrote:

sound really as some bug.. and similar to system() call.
my versions is:

- it could be that strings are expected to be 16-byte aligned

- that there's some bug with converting to null-terminated C string

Great! It's be nice to get this and system calls working in one shot... how do we proceed? How do we test? I'm willing to help...

if there some bug, it must be in NBExternalString
which responsible for marshalling strings.
try to change the alignment for the pointer and see how it goes in

reserveStackBytes: numBytesOrBlock andStoreAddrTo: aTemp

because right now it aligns the total space to reserve on stack
(amount to subtract from SP), but not SP itself
alignment should use powers of 2 , of course.

Cheers,
Sean

View this message in context: Re: NativeBoost String Handling Bug?

Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

--
Best regards,
Igor Stasenko.

--
Best regards,
Igor Stasenko.

If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860p4726884.html

To unsubscribe from NativeBoost String Handling Bug?, click here.
NAML

Cheers,
Sean

View this message in context: Re: NativeBoost String Handling Bug?
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

--
Best regards,
Igor Stasenko.

Sean P. DeNigris

Re: NativeBoost String Handling Bug?

Administrator

In reply to this post by Igor Stasenko

On Dec 2, 2013, at 9:08 PM, Igor Stasenko [via Smalltalk] <[hidden email]> wrote:

try and see if it works for you (and try syscall too, if yes then i think we can finally close the bug entry).

Yes!!!!!!!!!!!!!!! FMOD is now working and so is system call:

run: str
"self run: 'open http://www.google.com'."

<primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode >
^ self nbCall: #( int system (String str) ) module: NativeBoost CLibrary

Thank you, Igor :)

Cheers,
Sean

Sean P. DeNigris

Re: NativeBoost String Handling Bug?

Administrator

In reply to this post by Igor Stasenko

Igor Stasenko wrote

if yes then i think we can finally close the bug entry).

I updated the issue and made your packages into a slice:
https://pharo.fogbugz.com/default.asp?7542
SLICE-Issue-7542-NB-system-example-SeanDeNigris.1

Cheers,
Sean

Igor Stasenko

Re: NativeBoost String Handling Bug?

Yes, thank you.

On 3 December 2013 05:57, Sean P. DeNigris <[hidden email]> wrote:

Igor Stasenko wrote

> if yes then i think we can finally close the bug entry).

I updated the issue and made your packages into a slice:
https://pharo.fogbugz.com/default.asp?7542
SLICE-Issue-7542-NB-system-example-SeanDeNigris.1

-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860p4726895.html

Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

--
Best regards,
Igor Stasenko.

Luc Fabresse

Re: NativeBoost String Handling Bug?

Congrats Sean!

and thanks Igor ;-)

#Luc

2013/12/3 Igor Stasenko <[hidden email]>

Yes, thank you.

On 3 December 2013 05:57, Sean P. DeNigris <[hidden email]> wrote:

Igor Stasenko wrote

> if yes then i think we can finally close the bug entry).

I updated the issue and made your packages into a slice:
https://pharo.fogbugz.com/default.asp?7542
SLICE-Issue-7542-NB-system-example-SeanDeNigris.1

-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860p4726895.html

Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

--
Best regards,
Igor Stasenko.

Stéphane Ducasse

Re: NativeBoost String Handling Bug?

In reply to this post by Sean P. DeNigris

You know what?
It will not be integrated because apparently the monkey tagged it as invalid.

I have no idea why. I hate this automatic down grading. May be we should have a different tags to make the difference
between

work needed = nothing was done or something but it was never in the state where we could think it should be integrated
was integration ready = it was ready but something happen

Stef

> Igor Stasenko wrote
>> if yes then i think we can finally close the bug entry).
>
> I updated the issue and made your packages into a slice:
> https://pharo.fogbugz.com/default.asp?7542
> SLICE-Issue-7542-NB-system-example-SeanDeNigris.1
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860p4726895.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>

Igor Stasenko

Re: NativeBoost String Handling Bug?

i have no idea, but following is not related to what changes i did:

 ./pharo Pharo.image update --from-file=updates30.staged

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (MBUpdateDevCommand is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

MBAddDescriptionCommandTest>>testExecute (MBAddDescriptionCommand is Undeclared) 

MBConfigurationInfoTest>>testInitialization (ConfigurationOfVersionner is Undeclared) 

MBAbstractVersionInfo>>cmdSetCurrentVersion (MBSetCurrentVersionCommand is Undeclared) 

MTProject>>addDependentProject:from:withVersion:loads:(repository is shadowed)

On 3 December 2013 10:17, Stéphane Ducasse <[hidden email]> wrote:

You know what?
It will not be integrated because apparently the monkey tagged it as invalid.

I have no idea why. I hate this automatic down grading. May be we should have a different tags to make the difference
between

work needed = nothing was done or something but it was never in the state where we could think it should be integrated
was integration ready = it was ready but something happen

Stef

> Igor Stasenko wrote
>> if yes then i think we can finally close the bug entry).
>
> I updated the issue and made your packages into a slice:
> https://pharo.fogbugz.com/default.asp?7542
> SLICE-Issue-7542-NB-system-example-SeanDeNigris.1
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860p4726895.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>

--
Best regards,
Igor Stasenko.

Stéphane Ducasse

Re: NativeBoost String Handling Bug?

Igor

where do you get this information?

Because I see

https://ci.inria.fr/pharo/job/Pharo-3.0-Issue-Validator/3549//artifact/validationReport.html

and it is different.

stef

On Dec 3, 2013, at 11:59 AM, Igor Stasenko <[hidden email]> wrote:

i have no idea, but following is not related to what changes i did:
 ./pharo Pharo.image update --from-file=updates30.staged

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (MBUpdateDevCommand is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

MBAddDescriptionCommandTest>>testExecute (MBAddDescriptionCommand is Undeclared) 

MBConfigurationInfoTest>>testInitialization (ConfigurationOfVersionner is Undeclared) 

MBAbstractVersionInfo>>cmdSetCurrentVersion (MBSetCurrentVersionCommand is Undeclared) 

MTProject>>addDependentProject:from:withVersion:loads:(repository is shadowed)
On 3 December 2013 10:17, Stéphane Ducasse <[hidden email]> wrote:

You know what?
It will not be integrated because apparently the monkey tagged it as invalid.

I have no idea why. I hate this automatic down grading. May be we should have a different tags to make the difference
between

work needed = nothing was done or something but it was never in the state where we could think it should be integrated
was integration ready = it was ready but something happen

Stef

> Igor Stasenko wrote
>> if yes then i think we can finally close the bug entry).
>
> I updated the issue and made your packages into a slice:
> https://pharo.fogbugz.com/default.asp?7542
> SLICE-Issue-7542-NB-system-example-SeanDeNigris.1
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860p4726895.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>

--
Best regards,
Igor Stasenko.

Igor Stasenko

Re: NativeBoost String Handling Bug?

apparently i was looking at wrong place, and according to report there's merge conflict.

why? because i merged everything before commit.

On 3 December 2013 12:09, Stéphane Ducasse <[hidden email]> wrote:

Igor

where do you get this information?
Because I see
https://ci.inria.fr/pharo/job/Pharo-3.0-Issue-Validator/3549//artifact/validationReport.html

and it is different.
stef
On Dec 3, 2013, at 11:59 AM, Igor Stasenko <[hidden email]> wrote:
i have no idea, but following is not related to what changes i did:
 ./pharo Pharo.image update --from-file=updates30.staged

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (MBUpdateDevCommand is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

MBAddDescriptionCommandTest>>testExecute (MBAddDescriptionCommand is Undeclared) 

MBConfigurationInfoTest>>testInitialization (ConfigurationOfVersionner is Undeclared) 

MBAbstractVersionInfo>>cmdSetCurrentVersion (MBSetCurrentVersionCommand is Undeclared) 

MTProject>>addDependentProject:from:withVersion:loads:(repository is shadowed) 
On 3 December 2013 10:17, Stéphane Ducasse <[hidden email]> wrote:

You know what?
It will not be integrated because apparently the monkey tagged it as invalid.

I have no idea why. I hate this automatic down grading. May be we should have a different tags to make the difference
between

work needed = nothing was done or something but it was never in the state where we could think it should be integrated
was integration ready = it was ready but something happen

Stef

> Igor Stasenko wrote
>> if yes then i think we can finally close the bug entry).
>
> I updated the issue and made your packages into a slice:
> https://pharo.fogbugz.com/default.asp?7542
> SLICE-Issue-7542-NB-system-example-SeanDeNigris.1
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860p4726895.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>

--
Best regards,
Igor Stasenko.

--
Best regards,
Igor Stasenko.

Benjamin Van Ryseghem (Pharo)

Re: NativeBoost String Handling Bug?

I testify, there are 2 conflicts

Ben

On 03 Dec 2013, at 12:44, Igor Stasenko <[hidden email]> wrote:

apparently i was looking at wrong place, and according to report there's merge conflict.
why? because i merged everything before commit.
On 3 December 2013 12:09, Stéphane Ducasse <[hidden email]> wrote:
Igor

where do you get this information?
Because I see
https://ci.inria.fr/pharo/job/Pharo-3.0-Issue-Validator/3549//artifact/validationReport.html

and it is different.
stef
On Dec 3, 2013, at 11:59 AM, Igor Stasenko <[hidden email]> wrote:
i have no idea, but following is not related to what changes i did:
 ./pharo Pharo.image update --from-file=updates30.staged

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (MBUpdateDevCommand is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

MBAddDescriptionCommandTest>>testExecute (MBAddDescriptionCommand is Undeclared) 

MBConfigurationInfoTest>>testInitialization (ConfigurationOfVersionner is Undeclared) 

MBAbstractVersionInfo>>cmdSetCurrentVersion (MBSetCurrentVersionCommand is Undeclared) 

MTProject>>addDependentProject:from:withVersion:loads:(repository is shadowed) 
On 3 December 2013 10:17, Stéphane Ducasse <[hidden email]> wrote:

You know what?
It will not be integrated because apparently the monkey tagged it as invalid.

I have no idea why. I hate this automatic down grading. May be we should have a different tags to make the difference
between

work needed = nothing was done or something but it was never in the state where we could think it should be integrated
was integration ready = it was ready but something happen

Stef

> Igor Stasenko wrote
>> if yes then i think we can finally close the bug entry).
>
> I updated the issue and made your packages into a slice:
> https://pharo.fogbugz.com/default.asp?7542
> SLICE-Issue-7542-NB-system-example-SeanDeNigris.1
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860p4726895.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>

--
Best regards,
Igor Stasenko.
--
Best regards,
Igor Stasenko.

Igor Stasenko

Re: NativeBoost String Handling Bug?

Yes

"protocol: private"
anonymousSubclassInitElementType: aTypeName
    "create and initialize the anonymous subclass of me"

    | newSubclass |
    newSubclass := self classBuilder anonymousSubclassOf: NBExternalArray.
    newSubclass initElementType: aTypeName.
    ^ newSubclass

vs

"protocol: private"
anonymousSubclassInitElementType: aTypeName
    "create and initialize the anonymous subclass of me"

    | newSubclass |
    newSubclass := AnonymousClassInstaller make: [ :builder |
        "we're not using 'self' to avoid wrong subclassing from anonymous subclass"
        builder superclass: NBExternalArray ].
    newSubclass initElementType: aTypeName.
    ^ newSubclass

And

"protocol: class factory"
getClassForType: aTypeName
    "Do not confuse.! This method answers an anonymous class, a subclass of NBExternalTypeValue,
    which can be used for instantiation later i.e:

    floatTypeClass := NBExternalTypeValue ofType: 'float'.

    float := floatTypeClass new.
    float value: 1.5.
    float value.

    "

    | newSubclass |
    newSubclass := self classBuilder anonymousSubclassOf: NBExternalTypeValue.
    newSubclass valueType: aTypeName.
    ^ newSubclass

vs

"protocol: class factory"
getClassForType: aTypeName
    "Do not confuse.! This method answers an anonymous class, a subclass of NBExternalTypeValue,
    which can be used for instantiation later i.e:

    floatTypeClass := NBTypeValue ofType: 'float'.

    float := floatTypeClass new.
    float value: 1.5.
    float value.

    "

    | newSubclass |
    newSubclass := AnonymousClassInstaller make: [ :builder |
        "we're not using 'self' to avoid wrong subclassing from anonymous subclass "
        builder superclass: NBExternalTypeValue ].
    newSubclass initValueType: aTypeName.
    ^ newSubclass

To anyone who changed this, can i have some canonical protocol for creating anonymous subclasses
without referring to fuzzy , vague and unknown (as to me) AnonymousClassInstaller

or other strange globals?

On 3 December 2013 13:01, Benjamin <[hidden email]> wrote:

I testify, there are 2 conflicts

Ben
On 03 Dec 2013, at 12:44, Igor Stasenko <[hidden email]> wrote:
apparently i was looking at wrong place, and according to report there's merge conflict.

why? because i merged everything before commit.
On 3 December 2013 12:09, Stéphane Ducasse <[hidden email]> wrote:
Igor

where do you get this information?
Because I see
https://ci.inria.fr/pharo/job/Pharo-3.0-Issue-Validator/3549//artifact/validationReport.html

and it is different.
stef
On Dec 3, 2013, at 11:59 AM, Igor Stasenko <[hidden email]> wrote:
i have no idea, but following is not related to what changes i did:
 ./pharo Pharo.image update --from-file=updates30.staged

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (MBUpdateDevCommand is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

MBAddDescriptionCommandTest>>testExecute (MBAddDescriptionCommand is Undeclared) 

MBConfigurationInfoTest>>testInitialization (ConfigurationOfVersionner is Undeclared) 

MBAbstractVersionInfo>>cmdSetCurrentVersion (MBSetCurrentVersionCommand is Undeclared) 

MTProject>>addDependentProject:from:withVersion:loads:(repository is shadowed) 
On 3 December 2013 10:17, Stéphane Ducasse <[hidden email]> wrote:

You know what?
It will not be integrated because apparently the monkey tagged it as invalid.

I have no idea why. I hate this automatic down grading. May be we should have a different tags to make the difference
between

work needed = nothing was done or something but it was never in the state where we could think it should be integrated
was integration ready = it was ready but something happen

Stef

> Igor Stasenko wrote
>> if yes then i think we can finally close the bug entry).
>
> I updated the issue and made your packages into a slice:
> https://pharo.fogbugz.com/default.asp?7542
> SLICE-Issue-7542-NB-system-example-SeanDeNigris.1
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860p4726895.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>

--
Best regards,
Igor Stasenko.
--
Best regards,
Igor Stasenko.

--
Best regards,
Igor Stasenko.

EstebanLM

Re: NativeBoost String Handling Bug?

I'm ok to add some convenient methods to class installers.

just that I do not have time to do it right now, so be my guest :)

Esteban

On Tue, Dec 3, 2013 at 1:10 PM, Igor Stasenko <[hidden email]> wrote:

Yes

"protocol: private"
anonymousSubclassInitElementType: aTypeName
    "create and initialize the anonymous subclass of me"

    | newSubclass |
    newSubclass := self classBuilder anonymousSubclassOf: NBExternalArray.
    newSubclass initElementType: aTypeName.
    ^ newSubclass

vs

"protocol: private"
anonymousSubclassInitElementType: aTypeName
    "create and initialize the anonymous subclass of me"

    | newSubclass |
    newSubclass := AnonymousClassInstaller make: [ :builder |
        "we're not using 'self' to avoid wrong subclassing from anonymous subclass"
        builder superclass: NBExternalArray ].
    newSubclass initElementType: aTypeName.
    ^ newSubclass

And

"protocol: class factory"
getClassForType: aTypeName
    "Do not confuse.! This method answers an anonymous class, a subclass of NBExternalTypeValue,
    which can be used for instantiation later i.e:

    floatTypeClass := NBExternalTypeValue ofType: 'float'.

    float := floatTypeClass new.
    float value: 1.5.
    float value.

    "

    | newSubclass |
    newSubclass := self classBuilder anonymousSubclassOf: NBExternalTypeValue.
    newSubclass valueType: aTypeName.
    ^ newSubclass

vs

"protocol: class factory"
getClassForType: aTypeName
    "Do not confuse.! This method answers an anonymous class, a subclass of NBExternalTypeValue,
    which can be used for instantiation later i.e:

    floatTypeClass := NBTypeValue ofType: 'float'.

    float := floatTypeClass new.
    float value: 1.5.
    float value.

    "

    | newSubclass |
    newSubclass := AnonymousClassInstaller make: [ :builder |
        "we're not using 'self' to avoid wrong subclassing from anonymous subclass "
        builder superclass: NBExternalTypeValue ].
    newSubclass initValueType: aTypeName.
    ^ newSubclass

To anyone who changed this, can i have some canonical protocol for creating anonymous subclasses
without referring to fuzzy , vague and unknown (as to me) AnonymousClassInstaller
or other strange globals?
On 3 December 2013 13:01, Benjamin <[hidden email]> wrote:
I testify, there are 2 conflicts

Ben
On 03 Dec 2013, at 12:44, Igor Stasenko <[hidden email]> wrote:
apparently i was looking at wrong place, and according to report there's merge conflict.

why? because i merged everything before commit.
On 3 December 2013 12:09, Stéphane Ducasse <[hidden email]> wrote:
Igor

where do you get this information?
Because I see
https://ci.inria.fr/pharo/job/Pharo-3.0-Issue-Validator/3549//artifact/validationReport.html

and it is different.
stef
On Dec 3, 2013, at 11:59 AM, Igor Stasenko <[hidden email]> wrote:
i have no idea, but following is not related to what changes i did:
 ./pharo Pharo.image update --from-file=updates30.staged

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

VersionnerProjectToolBar>>update (MBUpdateDevCommand is Undeclared) 

VersionnerProjectToolBar>>update (update is Undeclared) 

MBAddDescriptionCommandTest>>testExecute (MBAddDescriptionCommand is Undeclared) 

MBConfigurationInfoTest>>testInitialization (ConfigurationOfVersionner is Undeclared) 

MBAbstractVersionInfo>>cmdSetCurrentVersion (MBSetCurrentVersionCommand is Undeclared) 

MTProject>>addDependentProject:from:withVersion:loads:(repository is shadowed) 
On 3 December 2013 10:17, Stéphane Ducasse <[hidden email]> wrote:

You know what?
It will not be integrated because apparently the monkey tagged it as invalid.

I have no idea why. I hate this automatic down grading. May be we should have a different tags to make the difference
between

work needed = nothing was done or something but it was never in the state where we could think it should be integrated
was integration ready = it was ready but something happen

Stef

> Igor Stasenko wrote
>> if yes then i think we can finally close the bug entry).
>
> I updated the issue and made your packages into a slice:
> https://pharo.fogbugz.com/default.asp?7542
> SLICE-Issue-7542-NB-system-example-SeanDeNigris.1
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860p4726895.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>

--
Best regards,
Igor Stasenko.
--
Best regards,
Igor Stasenko.
--
Best regards,
Igor Stasenko.

Igor Stasenko

Re: NativeBoost String Handling Bug?

Yes, when we discussed this with Martin (for a first time on that topic, i guess)

all i wanted is a convenience method to _just_ make anonymous subclass..

how long this expression could be?

it should be as long as:

myClass createAnonymousSubclass.

and what we have instead?

First:

self classBuilder anonymousSubclassOf: NBExternalArray.

then

newSubclass := AnonymousClassInstaller make: [ :builder |
builder superclass: NBExternalArray ].

this is unacceptable.

Because imagine one day you would want to port such code, (not necessary NB, but code which creates and
uses anonymous subclasses), which code for porter, would be easier to understand how to port it if another dialect will miss any AnonymousClassInstaller?

--
Best regards,
Igor Stasenko.