Hi, I'm trying to generate a vm... loading ConfigurationOfVMMaker version 1.4, then updating WMMaker package to latest version (200), but the generator, it is sending a DNU:
while calling:
'From Pharo-1.1.1-- of 12 September 2010 [Latest update: #11414] on 6 November 2010 at 3:00:14 pm'!
!String methodsFor: '*VMMaker-Translation to C' stamp: 'dtl 10/25/2009 14:31'! replaceLastOccurrence: oldSubstring with: newSubstring "Answer a copy with the last occurrence of oldSubstring replaced by newSubstring."
" 'int i' replaceLastOccurrence: 'i' with: 'i2' " " 'void *v' replaceLastOccurrence: 'v' with: 'v2' " " 'int intxintxintx' replaceLastOccurrence: 'i' with: 'I2' " " 'int intxintxintx' replaceLastOccurrence: 'FOO' with: 'BAR' " " 'int intxintxintx' replaceLastOccurrence: '' with: 'BAZ' "
^ self class streamContents: [:ws | | pos rs | rs := ReadStream on: self. pos := self findLastOccuranceOfString: oldSubstring startingAt: 1. pos > 0 ifTrue: [ws nextPutAll: (rs next: pos - 1); nextPutAll: newSubstring. rs next: oldSubstring size]. ws nextPutAll: rs upToEnd]! !
the DNU is with: findLastOccuranceOfString: oldSubstring startingAt: 1
Cheers, Esteban
On Sat, 6 Nov 2010, Esteban Lorenzano wrote:
Hi, I'm trying to generate a vm... loading ConfigurationOfVMMaker version 1.4, then updating WMMaker package to latest version (200), but the generator, it is sending a DNU:
while calling:
'From Pharo-1.1.1-- of 12 September 2010 [Latest update: #11414] on 6 November 2010 at 3:00:14 pm'!
!String methodsFor: '*VMMaker-Translation to C' stamp: 'dtl 10/25/2009 14:31'! replaceLastOccurrence: oldSubstring with: newSubstring "Answer a copy with the last occurrence of oldSubstring replaced by newSubstring."
" 'int i' replaceLastOccurrence: 'i' with: 'i2' " " 'void *v' replaceLastOccurrence: 'v' with: 'v2' " " 'int intxintxintx' replaceLastOccurrence: 'i' with: 'I2' " " 'int intxintxintx' replaceLastOccurrence: 'FOO' with: 'BAR' " " 'int intxintxintx' replaceLastOccurrence: '' with: 'BAZ' "
^ self class streamContents: [:ws | | pos rs | rs := ReadStream on: self. pos := self findLastOccuranceOfString: oldSubstring startingAt: 1. pos > 0 ifTrue: [ws nextPutAll: (rs next: pos - 1); nextPutAll: newSubstring. rs next: oldSubstring size]. ws nextPutAll: rs upToEnd]! !
the DNU is with: findLastOccuranceOfString: oldSubstring startingAt: 1
It's a typo that should be fixed in VMMaker. The correct method name is findLastOccurr_e_nceOfString:startingAt: without the underscores.
Levente
Cheers, Esteban
On Sat, Nov 06, 2010 at 07:33:37PM +0100, Levente Uzonyi wrote:
On Sat, 6 Nov 2010, Esteban Lorenzano wrote:
Hi, I'm trying to generate a vm... loading ConfigurationOfVMMaker version 1.4, then updating WMMaker package to latest version (200), but the generator, it is sending a DNU:
while calling:
'From Pharo-1.1.1-- of 12 September 2010 [Latest update: #11414] on 6 November 2010 at 3:00:14 pm'!
!String methodsFor: '*VMMaker-Translation to C' stamp: 'dtl 10/25/2009 14:31'! replaceLastOccurrence: oldSubstring with: newSubstring "Answer a copy with the last occurrence of oldSubstring replaced by newSubstring."
" 'int i' replaceLastOccurrence: 'i' with: 'i2' " " 'void *v' replaceLastOccurrence: 'v' with: 'v2' " " 'int intxintxintx' replaceLastOccurrence: 'i' with: 'I2' " " 'int intxintxintx' replaceLastOccurrence: 'FOO' with: 'BAR' " " 'int intxintxintx' replaceLastOccurrence: '' with: 'BAZ' "
^ self class streamContents: [:ws | | pos rs | rs := ReadStream on: self. pos := self findLastOccuranceOfString: oldSubstring startingAt: 1. pos > 0 ifTrue: [ws nextPutAll: (rs next: pos - 1); nextPutAll: newSubstring. rs next: oldSubstring size]. ws nextPutAll: rs upToEnd]! !
the DNU is with: findLastOccuranceOfString: oldSubstring startingAt: 1
It's a typo that should be fixed in VMMaker. The correct method name is findLastOccurr_e_nceOfString:startingAt: without the underscores.
Fixed in VMMaker-dtl.201.
This was a left over reference to the deprecated #findLastOccuranceOfString:startingAt: which is still present in the VMMaker package but should no longer have been in use. Thanks for finding it.
Dave
mmm... now the "inlining step X" is taking for years... is that normal?
Cheers, Esteban
On 2010-11-06 18:08:59 -0300, "David T. Lewis" lewis@mail.msen.com said:
On Sat, Nov 06, 2010 at 07:33:37PM +0100, Levente Uzonyi wrote:
On Sat, 6 Nov 2010, Esteban Lorenzano wrote:
Hi, I'm trying to generate a vm... loading ConfigurationOfVMMaker version 1.4, then updating WMMaker package to latest version (200), but the generator, it is sending a DNU:
while calling:
'From Pharo-1.1.1-- of 12 September 2010 [Latest update: #11414] on 6 November 2010 at 3:00:14 pm'!
!String methodsFor: '*VMMaker-Translation to C' stamp: 'dtl 10/25/2009 14:31'! replaceLastOccurrence: oldSubstring with: newSubstring "Answer a copy with the last occurrence of oldSubstring replaced by newSubstring."
" 'int i' replaceLastOccurrence: 'i' with: 'i2' " " 'void *v' replaceLastOccurrence: 'v' with: 'v2' " " 'int intxintxintx' replaceLastOccurrence: 'i' with: 'I2' " " 'int intxintxintx' replaceLastOccurrence: 'FOO' with: 'BAR' " " 'int intxintxintx' replaceLastOccurrence: '' with: 'BAZ' "
^ self class streamContents: [:ws | | pos rs | rs := ReadStream on: self. pos := self findLastOccuranceOfString: oldSubstring startingAt: 1. pos > 0 ifTrue: [ws nextPutAll: (rs next: pos - 1); nextPutAll: newSubstring. rs next: oldSubstring size]. ws nextPutAll: rs upToEnd]! !
the DNU is with: findLastOccuranceOfString: oldSubstring startingAt: 1
It's a typo that should be fixed in VMMaker. The correct method name is findLastOccurr_e_nceOfString:startingAt: without the underscores.
Fixed in VMMaker-dtl.201.
This was a left over reference to the deprecated #findLastOccuranceOfString:startingAt: which is still present in the VMMaker package but should no longer have been in use. Thanks for finding it.
Dave
I mean... 2hs and still not finished :(
On 2010-11-06 20:18:59 -0300, Esteban Lorenzano estebanlm@gmail.com said:
mmm... now the "inlining step X" is taking for years... is that normal?
Cheers, Esteban
On 2010-11-06 18:08:59 -0300, "David T. Lewis" lewis@mail.msen.com said:
On Sat, Nov 06, 2010 at 07:33:37PM +0100, Levente Uzonyi wrote:
On Sat, 6 Nov 2010, Esteban Lorenzano wrote:
Hi, I'm trying to generate a vm... loading ConfigurationOfVMMaker version 1.4, then updating WMMaker package to latest version (200), but the generator, it is sending a DNU:
while calling:
'From Pharo-1.1.1-- of 12 September 2010 [Latest update: #11414] on 6 November 2010 at 3:00:14 pm'!
!String methodsFor: '*VMMaker-Translation to C' stamp: 'dtl 10/25/2009 14:31'! replaceLastOccurrence: oldSubstring with: newSubstring "Answer a copy with the last occurrence of oldSubstring replaced by newSubstring."
" 'int i' replaceLastOccurrence: 'i' with: 'i2' " " 'void *v' replaceLastOccurrence: 'v' with: 'v2' " " 'int intxintxintx' replaceLastOccurrence: 'i' with: 'I2' " " 'int intxintxintx' replaceLastOccurrence: 'FOO' with: 'BAR' " " 'int intxintxintx' replaceLastOccurrence: '' with: 'BAZ' "
^ self class streamContents: [:ws | | pos rs | rs := ReadStream on: self. pos := self findLastOccuranceOfString: oldSubstring startingAt: 1. pos > 0 ifTrue: [ws nextPutAll: (rs next: pos - 1); nextPutAll: newSubstring. rs next: oldSubstring size]. ws nextPutAll: rs upToEnd]! !
the DNU is with: findLastOccuranceOfString: oldSubstring startingAt: 1
It's a typo that should be fixed in VMMaker. The correct method name is findLastOccurr_e_nceOfString:startingAt: without the underscores.
Fixed in VMMaker-dtl.201.
This was a left over reference to the deprecated #findLastOccuranceOfString:startingAt: which is still present in the VMMaker package but should no longer have been in use. Thanks for finding it.
Dave
it should finish in less that 5 minutes.
On Sat, Nov 6, 2010 at 8:21 PM, Esteban Lorenzano estebanlm@gmail.comwrote:
I mean... 2hs and still not finished :(
On 2010-11-06 20:18:59 -0300, Esteban Lorenzano estebanlm@gmail.com said:
mmm... now the "inlining step X" is taking for years... is that normal?
Cheers, Esteban
On 2010-11-06 18:08:59 -0300, "David T. Lewis" lewis@mail.msen.com said:
On Sat, Nov 06, 2010 at 07:33:37PM +0100, Levente Uzonyi wrote:
On Sat, 6 Nov 2010, Esteban Lorenzano wrote:
Hi, I'm trying to generate a vm... loading ConfigurationOfVMMaker version 1.4, then updating WMMaker package to latest version (200), but the generator, it is sending a DNU:
while calling:
'From Pharo-1.1.1-- of 12 September 2010 [Latest update: #11414] on 6 November 2010 at 3:00:14 pm'!
!String methodsFor: '*VMMaker-Translation to C' stamp: 'dtl 10/25/2009 14:31'! replaceLastOccurrence: oldSubstring with: newSubstring "Answer a copy with the last occurrence of oldSubstring replaced by newSubstring."
" 'int i' replaceLastOccurrence: 'i' with: 'i2' " " 'void *v' replaceLastOccurrence: 'v' with: 'v2' " " 'int intxintxintx' replaceLastOccurrence: 'i' with: 'I2' " " 'int intxintxintx' replaceLastOccurrence: 'FOO' with: 'BAR' " " 'int intxintxintx' replaceLastOccurrence: '' with: 'BAZ' " ^ self class streamContents: [:ws | | pos rs |
rs := ReadStream on: self. pos := self findLastOccuranceOfString: oldSubstring startingAt: 1. pos > 0 ifTrue: [ws nextPutAll: (rs next: pos - 1); nextPutAll: newSubstring. rs next: oldSubstring size]. ws nextPutAll: rs upToEnd]! !
the DNU is with: findLastOccuranceOfString: oldSubstring startingAt: 1
It's a typo that should be fixed in VMMaker. The correct method name is findLastOccurr_e_nceOfString:startingAt: without the underscores.
Fixed in VMMaker-dtl.201.
This was a left over reference to the deprecated #findLastOccuranceOfString:startingAt: which is still present in the VMMaker package but should no longer have been in use. Thanks for finding it.
Dave
If you have MiscInterpreterPlugin in the list, try removing it. I don't know why but it sometimes make VMMaker inline forever. IIRC MiscInterpreterPlugin contains just optimizations for common operations like string copying, so everything should work fine without it (a bit slower of course).
Regards, Javier.
On Sat, Nov 6, 2010 at 9:41 PM, Mariano Martinez Peck <marianopeck@gmail.com
wrote:
it should finish in less that 5 minutes.
On Sat, Nov 6, 2010 at 8:21 PM, Esteban Lorenzano estebanlm@gmail.comwrote:
I mean... 2hs and still not finished :(
On 2010-11-06 20:18:59 -0300, Esteban Lorenzano estebanlm@gmail.com said:
mmm... now the "inlining step X" is taking for years... is that normal?
Cheers, Esteban
On 2010-11-06 18:08:59 -0300, "David T. Lewis" lewis@mail.msen.com said:
On Sat, Nov 06, 2010 at 07:33:37PM +0100, Levente Uzonyi wrote:
On Sat, 6 Nov 2010, Esteban Lorenzano wrote:
Hi, I'm trying to generate a vm... loading ConfigurationOfVMMaker version 1.4, then updating WMMaker package to latest version (200), but the generator, it is sending a DNU:
while calling:
'From Pharo-1.1.1-- of 12 September 2010 [Latest update: #11414] on 6 November 2010 at 3:00:14 pm'!
!String methodsFor: '*VMMaker-Translation to C' stamp: 'dtl 10/25/2009 14:31'! replaceLastOccurrence: oldSubstring with: newSubstring "Answer a copy with the last occurrence of oldSubstring replaced by newSubstring."
" 'int i' replaceLastOccurrence: 'i' with: 'i2' " " 'void *v' replaceLastOccurrence: 'v' with: 'v2' " " 'int intxintxintx' replaceLastOccurrence: 'i' with: 'I2' " " 'int intxintxintx' replaceLastOccurrence: 'FOO' with: 'BAR' " " 'int intxintxintx' replaceLastOccurrence: '' with: 'BAZ' " ^ self class streamContents: [:ws | | pos rs |
rs := ReadStream on: self. pos := self findLastOccuranceOfString: oldSubstring startingAt: 1. pos > 0 ifTrue: [ws nextPutAll: (rs next: pos - 1); nextPutAll: newSubstring. rs next: oldSubstring size]. ws nextPutAll: rs upToEnd]! !
the DNU is with: findLastOccuranceOfString: oldSubstring startingAt: 1
It's a typo that should be fixed in VMMaker. The correct method name is findLastOccurr_e_nceOfString:startingAt: without the underscores.
Fixed in VMMaker-dtl.201.
This was a left over reference to the deprecated #findLastOccuranceOfString:startingAt: which is still present in the VMMaker package but should no longer have been in use. Thanks for finding it.
Dave
No of course it is not normal, and as Eliot said you are probably stuck in a recursion for some reason or another. Use <alt>-period to interrupt and get a debugger to find out what went wrong.
Your original message suggests that there was something not quite right in your image. You were getting a DNU for a message that should have existed but that was marked as deprecated. Now you apparently have a runaway recursion. Something is wrong and you are going to have to break out to a debugger to figure out what it is.
I don't normally use a pharo image so it's quite likely that I'm missing something here. But if you can open a debugger on the runaway process then I'm sure you will be able to spot the problem.
Dave
On Sat, Nov 06, 2010 at 09:41:40PM -0300, Mariano Martinez Peck wrote:
it should finish in less that 5 minutes.
On Sat, Nov 6, 2010 at 8:21 PM, Esteban Lorenzano estebanlm@gmail.comwrote:
I mean... 2hs and still not finished :(
On 2010-11-06 20:18:59 -0300, Esteban Lorenzano estebanlm@gmail.com said:
mmm... now the "inlining step X" is taking for years... is that normal?
Cheers, Esteban
On 2010-11-06 18:08:59 -0300, "David T. Lewis" lewis@mail.msen.com said:
On Sat, Nov 06, 2010 at 07:33:37PM +0100, Levente Uzonyi wrote:
On Sat, 6 Nov 2010, Esteban Lorenzano wrote:
Hi, I'm trying to generate a vm... loading ConfigurationOfVMMaker version 1.4, then updating WMMaker package to latest version (200), but the generator, it is sending a DNU:
while calling:
'From Pharo-1.1.1-- of 12 September 2010 [Latest update: #11414] on 6 November 2010 at 3:00:14 pm'!
!String methodsFor: '*VMMaker-Translation to C' stamp: 'dtl 10/25/2009 14:31'! replaceLastOccurrence: oldSubstring with: newSubstring "Answer a copy with the last occurrence of oldSubstring replaced by newSubstring."
" 'int i' replaceLastOccurrence: 'i' with: 'i2' " " 'void *v' replaceLastOccurrence: 'v' with: 'v2' " " 'int intxintxintx' replaceLastOccurrence: 'i' with: 'I2' " " 'int intxintxintx' replaceLastOccurrence: 'FOO' with: 'BAR' " " 'int intxintxintx' replaceLastOccurrence: '' with: 'BAZ' " ^ self class streamContents: [:ws | | pos rs |
rs := ReadStream on: self. pos := self findLastOccuranceOfString: oldSubstring startingAt: 1. pos > 0 ifTrue: [ws nextPutAll: (rs next: pos - 1); nextPutAll: newSubstring. rs next: oldSubstring size]. ws nextPutAll: rs upToEnd]! !
the DNU is with: findLastOccuranceOfString: oldSubstring startingAt: 1
It's a typo that should be fixed in VMMaker. The correct method name is findLastOccurr_e_nceOfString:startingAt: without the underscores.
Fixed in VMMaker-dtl.201.
This was a left over reference to the deprecated #findLastOccuranceOfString:startingAt: which is still present in the VMMaker package but should no longer have been in use. Thanks for finding it.
Dave
IIRC, it's because in Pharo the method included in MiscPrimitivePlugin, String>>#findSubstring..., is no longer the primitive, it's been moved to findSubstringViaPrimitive... findSubstring... now checks whether the primitive will work for the parameters (WideStrings vs ByteStrings), before it actually calls the primitive. To "fix" this for Pharo, change the method included in MiscPrimitivePlugin's "this is where my code should be located"-method.
Cheers, Henry
PS. Most of these issues have been discussed here before, do a search of the list and you are likely to find answers to speedbumps encountered along the way. Most notably, there's a MonticelloConfiguration which, as part of loading VMMaker, will modify it/the image in the ways needed for it to work on Pharo.
On 07.11.2010 04:57, David T. Lewis wrote:
No of course it is not normal, and as Eliot said you are probably stuck in a recursion for some reason or another. Use<alt>-period to interrupt and get a debugger to find out what went wrong.
Your original message suggests that there was something not quite right in your image. You were getting a DNU for a message that should have existed but that was marked as deprecated. Now you apparently have a runaway recursion. Something is wrong and you are going to have to break out to a debugger to figure out what it is.
I don't normally use a pharo image so it's quite likely that I'm missing something here. But if you can open a debugger on the runaway process then I'm sure you will be able to spot the problem.
Dave
On Sat, Nov 06, 2010 at 09:41:40PM -0300, Mariano Martinez Peck wrote:
it should finish in less that 5 minutes.
On Sat, Nov 6, 2010 at 8:21 PM, Esteban Lorenzanoestebanlm@gmail.comwrote:
I mean... 2hs and still not finished :(
On 2010-11-06 20:18:59 -0300, Esteban Lorenzanoestebanlm@gmail.com said:
mmm... now the "inlining step X" is taking for years... is that normal?
Cheers, Esteban
On 2010-11-06 18:08:59 -0300, "David T. Lewis"lewis@mail.msen.com said:
On Sat, Nov 06, 2010 at 07:33:37PM +0100, Levente Uzonyi wrote:
On Sat, 6 Nov 2010, Esteban Lorenzano wrote:
> Hi, > I'm trying to generate a vm... loading ConfigurationOfVMMaker version > 1.4, > then updating WMMaker package to latest version (200), but the > generator, > it is sending a DNU: > > while calling: > > 'From Pharo-1.1.1-- of 12 September 2010 [Latest update: #11414] on 6 > November 2010 at 3:00:14 pm'! > > !String methodsFor: '*VMMaker-Translation to C' stamp: 'dtl 10/25/2009 > 14:31'! > replaceLastOccurrence: oldSubstring with: newSubstring "Answer a > copy with the last occurrence of oldSubstring replaced by > newSubstring." > > " 'int i' replaceLastOccurrence: 'i' with: 'i2' " > " 'void *v' replaceLastOccurrence: 'v' with: 'v2' " > " 'int intxintxintx' replaceLastOccurrence: 'i' with: 'I2' " > " 'int intxintxintx' replaceLastOccurrence: 'FOO' with: 'BAR' " > " 'int intxintxintx' replaceLastOccurrence: '' with: 'BAZ' " > > ^ self class streamContents: [:ws | | pos rs | > rs > := ReadStream on: self. > pos := self findLastOccuranceOfString: > oldSubstring > startingAt: 1. > pos> 0 ifTrue: [ws nextPutAll: (rs next: pos - > 1); > nextPutAll: newSubstring. > rs next: oldSubstring > size]. > ws nextPutAll: rs upToEnd]! ! > > > the DNU is with: > findLastOccuranceOfString: oldSubstring startingAt: 1 > It's a typo that should be fixed in VMMaker. The correct method name is findLastOccurr_e_nceOfString:startingAt: without the underscores.
Fixed in VMMaker-dtl.201.
This was a left over reference to the deprecated #findLastOccuranceOfString:startingAt: which is still present in the VMMaker package but should no longer have been in use. Thanks for finding it.
Dave
On Sat, Nov 6, 2010 at 8:21 PM, Esteban Lorenzanoestebanlm@gmail.comwrote:
I mean... 2hs and still not finished :(
On 2010-11-06 20:18:59 -0300, Esteban Lorenzanoestebanlm@gmail.com said:
mmm... now the "inlining step X" is taking for years... is that normal?
Cheers, Esteban
On 07.11.2010 04:57, David T. Lewis wrote:
No of course it is not normal, and as Eliot said you are probably stuck in a recursion for some reason or another. Use<alt>-period to interrupt and get a debugger to find out what went wrong.
On Sun, Nov 07, 2010 at 11:32:04AM +0100, Henrik Sperre Johansen wrote:
IIRC, it's because in Pharo the method included in MiscPrimitivePlugin, String>>#findSubstring..., is no longer the primitive, it's been moved to findSubstringViaPrimitive... findSubstring... now checks whether the primitive will work for the parameters (WideStrings vs ByteStrings), before it actually calls the primitive. To "fix" this for Pharo, change the method included in MiscPrimitivePlugin's "this is where my code should be located"-method.
Cheers, Henry
PS. Most of these issues have been discussed here before, do a search of the list and you are likely to find answers to speedbumps encountered along the way. Most notably, there's a MonticelloConfiguration which, as part of loading VMMaker, will modify it/the image in the ways needed for it to work on Pharo.
Thanks, that may well be the problem that Mariano is seeing. In addition to discussion on the list, it is also documented in the bug report that you opened in Mantis (thank you for doing this!):
http://bugs.squeak.org/view.php?id=7479
I think that the proposed solution in Mantis 7479 is too fragile for my tastes. IMO the obvious solution is to fix the problem where it orginated, in the Pharo image. If that cannot be accomplished, then someone might want to just reimplement the primitive as an ordinary primitive (but that is not something that I am working on).
Dave
On 07.11.2010 15:27, David T. Lewis wrote:
On Sat, Nov 6, 2010 at 8:21 PM, Esteban Lorenzanoestebanlm@gmail.comwrote:
I mean... 2hs and still not finished :(
On 2010-11-06 20:18:59 -0300, Esteban Lorenzanoestebanlm@gmail.com said:
mmm... now the "inlining step X" is taking for years... is that normal?
Cheers, Esteban
On 07.11.2010 04:57, David T. Lewis wrote:
No of course it is not normal, and as Eliot said you are probably stuck in a recursion for some reason or another. Use<alt>-period to interrupt and get a debugger to find out what went wrong.
On Sun, Nov 07, 2010 at 11:32:04AM +0100, Henrik Sperre Johansen wrote:
IIRC, it's because in Pharo the method included in MiscPrimitivePlugin, String>>#findSubstring..., is no longer the primitive, it's been moved to findSubstringViaPrimitive... findSubstring... now checks whether the primitive will work for the parameters (WideStrings vs ByteStrings), before it actually calls the primitive. To "fix" this for Pharo, change the method included in MiscPrimitivePlugin's "this is where my code should be located"-method.
Cheers, Henry
PS. Most of these issues have been discussed here before, do a search of the list and you are likely to find answers to speedbumps encountered along the way. Most notably, there's a MonticelloConfiguration which, as part of loading VMMaker, will modify it/the image in the ways needed for it to work on Pharo.
Thanks, that may well be the problem that Mariano is seeing. In addition to discussion on the list, it is also documented in the bug report that you opened in Mantis (thank you for doing this!):
http://bugs.squeak.org/view.php?id=7479
I think that the proposed solution in Mantis 7479 is too fragile for my tastes.
Yeah, that's kind of the conclusion I came to as well :)
IMO the obvious solution is to fix the problem where it orginated, in the Pharo image.
Reverting would reintroduce getting invalid results from the plugin, without any workaround. Not really an option.
If that cannot be accomplished, then someone might want to just reimplement the primitive as an ordinary primitive (but that is not something that I am working on).
Dave
That's something I'd like to see as well. My personal feeling after looking into it, is that while the plugins-with-source-in-image idea is neat, there are too many pitfalls (refactoring, reproducibility, etc.) for it to be a good idea overall.
Cheers, Henry
On 11/7/2010 1:38 PM, Henrik Sperre Johansen wrote:
IMO the obvious solution is to fix the problem where it orginated, in the Pharo image.
Reverting would reintroduce getting invalid results from the plugin, without any workaround. Not really an option.
You could just fix the problem, you know :-) Seriously, if there's a bug in the plugin, perhaps we should fix that problem? After which reverting the method is obviously the correct solution for this problem.
Cheers, - Andreas
Den 08.11.2010 04:28, skrev Andreas Raab:
On 11/7/2010 1:38 PM, Henrik Sperre Johansen wrote:
IMO the obvious solution is to fix the problem where it orginated, in the Pharo image.
Reverting would reintroduce getting invalid results from the plugin, without any workaround. Not really an option.
You could just fix the problem, you know :-) Seriously, if there's a bug in the plugin, perhaps we should fix that problem? After which reverting the method is obviously the correct solution for this problem.
Cheers,
- Andreas
Oh absolutely, you just have to add the disclaimer: "Only run this image with a VM built from VMMaker with an image version newer than XY (Pharo) or ZI (Squeak). :-) (Which is what I meant with reproducibility issues, btw)
As for why I haven't just fixed it: For it to work correctly, I can't really see any way around choosing different paths based on whether either/both of the arguments are WideStrings. I was of the assumption you could only do type annotations in code primitives written this way, not lookup classes etc. I'd be delighted if that were incorrect, or there's some other way to differentiate the two my limited VM knowledge does not cover.
I imagine the match table part would have to be rewritten as well if one wanted to use it for Unicode-aware caseinsensitive search, there are 1050 1:1 upper/lowercase mappings in Unicode, last one at codepoint 66639. So in that case there's more work than one would expect, and a good solution would not be backwards-compatible either way.
Cheers, Henry
On 11/8/2010 1:30 AM, Henrik Johansen wrote:
Den 08.11.2010 04:28, skrev Andreas Raab:
On 11/7/2010 1:38 PM, Henrik Sperre Johansen wrote:
IMO the obvious solution is to fix the problem where it orginated, in the Pharo image.
Reverting would reintroduce getting invalid results from the plugin, without any workaround. Not really an option.
You could just fix the problem, you know :-) Seriously, if there's a bug in the plugin, perhaps we should fix that problem? After which reverting the method is obviously the correct solution for this problem.
Cheers,
- Andreas
Oh absolutely, you just have to add the disclaimer: "Only run this image with a VM built from VMMaker with an image version newer than XY (Pharo) or ZI (Squeak). :-) (Which is what I meant with reproducibility issues, btw)
Only for an interim period and only if you intend to use VMMaker.
As for why I haven't just fixed it: For it to work correctly, I can't really see any way around choosing different paths based on whether either/both of the arguments are WideStrings.
Let's start with a more basic question: What is the supposed problem? It may require different code paths, but it may not. Depends on what exactly the problem is.
I was of the assumption you could only do type annotations in code primitives written this way, not lookup classes etc. I'd be delighted if that were incorrect, or there's some other way to differentiate the two my limited VM knowledge does not cover.
I imagine the match table part would have to be rewritten as well if one wanted to use it for Unicode-aware caseinsensitive search, there are 1050 1:1 upper/lowercase mappings in Unicode, last one at codepoint 66639. So in that case there's more work than one would expect, and a good solution would not be backwards-compatible either way.
See above. I'm not clear what problem you're trying to address; it would help to state that clearly - perhaps you have a test handy that illustrates the problem?
Cheers, - Andreas
On Mon, Nov 08, 2010 at 10:30:21AM +0100, Henrik Johansen wrote:
Den 08.11.2010 04:28, skrev Andreas Raab:
On 11/7/2010 1:38 PM, Henrik Sperre Johansen wrote:
IMO the obvious solution is to fix the problem where it orginated, in the Pharo image.
Reverting would reintroduce getting invalid results from the plugin, without any workaround. Not really an option.
You could just fix the problem, you know :-) Seriously, if there's a bug in the plugin, perhaps we should fix that problem? After which reverting the method is obviously the correct solution for this problem.
Cheers,
- Andreas
Oh absolutely, you just have to add the disclaimer: "Only run this image with a VM built from VMMaker with an image version newer than XY (Pharo) or ZI (Squeak). :-) (Which is what I meant with reproducibility issues, btw)
Actually there is no problem with respect to image/VM compatibility at runtime. As long as the primitive has been built into the VM, it is going to work fine with any image that calls the named primitive.
But I think that Andreas is asking another question: What was the original motivation for renaming the method? And based on that, is there something that needs to be fixed in the primitive itself so that this will not be an issue? I don't really know the background on this myself, but it looks like there was a problem related to passing a WideString as a parameter to ByteString>>findSubstring:in:startingAt:matchTable:, and that the workaround in Pharo was to put an #isWideString check into #findSubstring:in:startingAt:matchTable: (which of course completely trashed the translation of #findSubstring:in:startingAt:matchTable: when translating to C).
The #isWideString check has a bad smell and suggests that there might be something that needs fixing in the primitive, after which the method could be reverted and everyone would be happy.
Unfortunately I am a modestly educated English speaker, so I am largely guessing as to the background on this issue ;)
Dave
On Mon, 8 Nov 2010, David T. Lewis wrote:
snip
But I think that Andreas is asking another question: What was the original motivation for renaming the method? And based on that, is there something that needs to be fixed in the primitive itself so that this will not be an issue? I don't really know the background on this myself, but it looks like there was a problem related to passing a WideString as a parameter to ByteString>>findSubstring:in:startingAt:matchTable:, and that the workaround in Pharo was to put an #isWideString check into #findSubstring:in:startingAt:matchTable: (which of course completely trashed the translation of #findSubstring:in:startingAt:matchTable: when translating to C).
The problem is that the method expects ByteStrings as arguments, but it won't fail if one of them is a WideString. Instead it returns wrong results. Here's an example (in Squeak):
ByteString new findSubstring: 'b' in: 'abc' asWideString startingAt: 1 matchTable: ((0 to: 255) as: ByteArray). "===> 0"
The result is 0, while it should be 2. The problem is worked around in Squeak by making sure that the primitive is not used in this case.
'abc' asWideString findString: 'b' startingAt: 1 caseSensitive: true. "===> 2"
Though a naive user can still use the method as shown here.
Levente
The #isWideString check has a bad smell and suggests that there might be something that needs fixing in the primitive, after which the method could be reverted and everyone would be happy.
Unfortunately I am a modestly educated English speaker, so I am largely guessing as to the background on this issue ;)
Dave
On 11/8/2010 5:08 PM, Levente Uzonyi wrote:
The problem is that the method expects ByteStrings as arguments, but it won't fail if one of them is a WideString. Instead it returns wrong results. Here's an example (in Squeak):
ByteString new findSubstring: 'b' in: 'abc' asWideString startingAt: 1 matchTable: ((0 to: 255) as: ByteArray). "===> 0"
The result is 0, while it should be 2. The problem is worked around in Squeak by making sure that the primitive is not used in this case.
'abc' asWideString findString: 'b' startingAt: 1 caseSensitive: true. "===> 2"
Though a naive user can still use the method as shown here.
Thanks. Looks like a problem in extracting string arguments in translated primitives. With Squeaksource being down again (should we move VMMaker to source.squeak.org?) I've attached a change set with a fix. This adds an additional check for char* arguments in translated prims to ensure that they're actually byte objects.
Cheers, - Andreas
On Mon, Nov 08, 2010 at 06:41:57PM -0800, Andreas Raab wrote:
On 11/8/2010 5:08 PM, Levente Uzonyi wrote:
The problem is that the method expects ByteStrings as arguments, but it won't fail if one of them is a WideString. Instead it returns wrong results. Here's an example (in Squeak):
ByteString new findSubstring: 'b' in: 'abc' asWideString startingAt: 1 matchTable: ((0 to: 255) as: ByteArray). "===> 0"
The result is 0, while it should be 2. The problem is worked around in Squeak by making sure that the primitive is not used in this case.
'abc' asWideString findString: 'b' startingAt: 1 caseSensitive: true. "===> 2"
Though a naive user can still use the method as shown here.
Thanks. Looks like a problem in extracting string arguments in translated primitives. With Squeaksource being down again (should we move VMMaker to source.squeak.org?) I've attached a change set with a fix. This adds an additional check for char* arguments in translated prims to ensure that they're actually byte objects.
Andreas,
Your fix does indeed resolve the underlying problem. I added it to VMMaker (with a note to Eliot to do likewise with oscog), and also added unit tests based on Levente's example. This should allow the various WideString workarounds to be removed once the updated VMs are in circulation.
Thanks, Dave
On Tue, Nov 9, 2010 at 7:30 PM, David T. Lewis lewis@mail.msen.com wrote:
On Mon, Nov 08, 2010 at 06:41:57PM -0800, Andreas Raab wrote:
On 11/8/2010 5:08 PM, Levente Uzonyi wrote:
The problem is that the method expects ByteStrings as arguments, but it won't fail if one of them is a WideString. Instead it returns wrong results. Here's an example (in Squeak):
ByteString new findSubstring: 'b' in: 'abc' asWideString startingAt: 1 matchTable: ((0 to: 255) as: ByteArray). "===> 0"
The result is 0, while it should be 2. The problem is worked around in Squeak by making sure that the primitive is not used in this case.
'abc' asWideString findString: 'b' startingAt: 1 caseSensitive: true. "===> 2"
Though a naive user can still use the method as shown here.
Thanks. Looks like a problem in extracting string arguments in translated primitives. With Squeaksource being down again (should we move VMMaker to source.squeak.org?) I've attached a change set with a fix. This adds an additional check for char* arguments in translated prims to ensure that they're actually byte objects.
Andreas,
Your fix does indeed resolve the underlying problem. I added it to VMMaker (with a note to Eliot to do likewise with oscog), and also added unit tests based on Levente's example. This should allow the various WideString workarounds to be removed once the updated VMs are in circulation.
OK, it's in my working version. It'll percolate out to oscog soon.
Thanks!
Thanks, Dave
Den 09.11.2010 03:41, skrev Andreas Raab:
Thanks. Looks like a problem in extracting string arguments in translated primitives. I've attached a change set with a fix. This adds an additional check for char* arguments in translated prims to ensure that they're actually byte objects.
Cheers,
- Andreas
Sorry for sort of dropping of the map and not providing any feedback sooner, work got real hectic this week. Nice solution though! Looking forward to seeing it included, I'll make sure all the safeguards in Pharo are removed and the method reverted once the new VMs are in distribution :D
The part I wrote about matchTable being in need of changes was more of a feature-request when I think about it, in that it would be nice to have a comparable function whose matchtable can also include substitutions outside the latin1-range. Then again, you'd probably also need normalization and other stuff in such a method...
Cheers, Henry
On Thu, Nov 11, 2010 at 12:43:57PM +0100, Henrik Johansen wrote:
Den 09.11.2010 03:41, skrev Andreas Raab:
Thanks. Looks like a problem in extracting string arguments in translated primitives. I've attached a change set with a fix. This adds an additional check for char* arguments in translated prims to ensure that they're actually byte objects.
Cheers,
- Andreas
Sorry for sort of dropping of the map and not providing any feedback sooner, work got real hectic this week. Nice solution though! Looking forward to seeing it included, I'll make sure all the safeguards in Pharo are removed and the method reverted once the new VMs are in distribution :D
Andreas' fix is now in VMMaker on SqueakSource, and Eliot is adding it to the cog branch, so this will be in all of the future VM builds. If you can follow up on removing the Pharo safeguards, that would be great. You would probably want to do that early next year after the updated VMs are in general circulation.
Thanks, Dave
Yes we will pay attention to do that Tx all!
Stef
On Nov 11, 2010, at 2:11 PM, David T. Lewis wrote:
On Thu, Nov 11, 2010 at 12:43:57PM +0100, Henrik Johansen wrote:
Den 09.11.2010 03:41, skrev Andreas Raab:
Thanks. Looks like a problem in extracting string arguments in translated primitives. I've attached a change set with a fix. This adds an additional check for char* arguments in translated prims to ensure that they're actually byte objects.
Cheers,
- Andreas
Sorry for sort of dropping of the map and not providing any feedback sooner, work got real hectic this week. Nice solution though! Looking forward to seeing it included, I'll make sure all the safeguards in Pharo are removed and the method reverted once the new VMs are in distribution :D
Andreas' fix is now in VMMaker on SqueakSource, and Eliot is adding it to the cog branch, so this will be in all of the future VM builds. If you can follow up on removing the Pharo safeguards, that would be great. You would probably want to do that early next year after the updated VMs are in general circulation.
Thanks, Dave
On Sat, Nov 6, 2010 at 4:18 PM, Esteban Lorenzano estebanlm@gmail.comwrote:
mmm... now the "inlining step X" is taking for years... is that normal?
No, and it's usually because of a recursion, e.g. Interpreter>someMethod self someMethod
IIRC, this will inline for ever.
HTH Eliot
Cheers, Esteban
On 2010-11-06 18:08:59 -0300, "David T. Lewis" lewis@mail.msen.com said:
On Sat, Nov 06, 2010 at 07:33:37PM +0100, Levente Uzonyi wrote:
On Sat, 6 Nov 2010, Esteban Lorenzano wrote:
Hi, I'm trying to generate a vm... loading ConfigurationOfVMMaker version 1.4, then updating WMMaker package to latest version (200), but the generator, it is sending a DNU:
while calling:
'From Pharo-1.1.1-- of 12 September 2010 [Latest update: #11414] on 6 November 2010 at 3:00:14 pm'!
!String methodsFor: '*VMMaker-Translation to C' stamp: 'dtl 10/25/2009 14:31'! replaceLastOccurrence: oldSubstring with: newSubstring "Answer a copy with the last occurrence of oldSubstring replaced by newSubstring."
" 'int i' replaceLastOccurrence: 'i' with: 'i2' " " 'void *v' replaceLastOccurrence: 'v' with: 'v2' " " 'int intxintxintx' replaceLastOccurrence: 'i' with: 'I2' " " 'int intxintxintx' replaceLastOccurrence: 'FOO' with: 'BAR' " " 'int intxintxintx' replaceLastOccurrence: '' with: 'BAZ' " ^ self class streamContents: [:ws | | pos rs |
rs := ReadStream on: self. pos := self findLastOccuranceOfString: oldSubstring startingAt: 1. pos > 0 ifTrue: [ws nextPutAll: (rs next: pos - 1); nextPutAll: newSubstring. rs next: oldSubstring size]. ws nextPutAll: rs upToEnd]! !
the DNU is with: findLastOccuranceOfString: oldSubstring startingAt: 1
It's a typo that should be fixed in VMMaker. The correct method name is findLastOccurr_e_nceOfString:startingAt: without the underscores.
Fixed in VMMaker-dtl.201.
This was a left over reference to the deprecated #findLastOccuranceOfString:startingAt: which is still present in the VMMaker package but should no longer have been in use. Thanks for finding it.
Dave
On 7 November 2010 01:21, Eliot Miranda eliot.miranda@gmail.com wrote:
On Sat, Nov 6, 2010 at 4:18 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
mmm... now the "inlining step X" is taking for years... is that normal?
No, and it's usually because of a recursion, e.g. Interpreter>someMethod self someMethod IIRC, this will inline for ever.
2 c.
I think i did something in Hydra to detect inlining recursion and throw an error. I don't remember if Squeak VMMaker having it too. This could prevent Esteban from waiting hours for nothing :)
HTH Eliot
On Sat, Nov 06, 2010 at 05:08:59PM -0400, David T. Lewis wrote:
On Sat, Nov 06, 2010 at 07:33:37PM +0100, Levente Uzonyi wrote:
On Sat, 6 Nov 2010, Esteban Lorenzano wrote:
the DNU is with: findLastOccuranceOfString: oldSubstring startingAt: 1
It's a typo that should be fixed in VMMaker. The correct method name is findLastOccurr_e_nceOfString:startingAt: without the underscores.
Fixed in VMMaker-dtl.201.
This was a left over reference to the deprecated #findLastOccuranceOfString:startingAt: which is still present in the VMMaker package but should no longer have been in use. Thanks for finding it.
FWIW, I remember now why that last reference to #findLastOccuranceOfString:startingAt: was still in the VMMaker package. I left it there intentionally to permit VMMaker to load in Squeak 3.8 and earlier images that did not yet have the new selector (the "misspelled" selector dates back to 2003, originating from a non-native English speaker, so completely understandable).
I just found this again after updating my VMMaker in a Squeak 3.8 image. But there are plenty of other things in VMMaker now that do not work in 3.8, so I won't worry about this any more.
Dave
vm-dev@lists.squeakfoundation.org