[tode_st] FFIExternalType>>basicHandle:at: --- subclassResponsibility

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[tode_st] FFIExternalType>>basicHandle:at: --- subclassResponsibility

Dale Henrichs-3
Mariano,

Next issue is that FFIExternalArray appears to not support #at: ... full
stack is at end and this is based on commit c2201af.

This looks like a "know problem" because Damien Pollet has a checkin:

   Name: UnifiedFFI-DamienPollet.49
   Author: DamienPollet
   Time: 25 March 2016, 3:14:03.411979 pm
   UUID: 29783fc7-36b1-49ff-a10e-cbd24b6e2cd0
   Ancestors: UnifiedFFI-EstebanLorenzano.48

   Comments and attempt at FFIExternalStructure >> #basicHandleAt:put:

That looks like it is intended to address the issue, but Esteban has not
incorporated it yet ...

Again, I don't believe that this is a show stopper, since I'm pretty
sure that I can extract the contents of the args via alternate,
nefarious means ... would be nice to have as well .. as it is I'm going
to have to spelunk around in the code looking for these "work arounds"
and re-port GemStone-GCI once the UFFI work is completed ...

Also it seems that I have to flush the cache on the Monticello Browser
before I can trust the results of "Changes" ... I haven't searched the
bugs (I don't have a fogbugz userid --- if that is still the system
being used) and I haven't searched the mailing list either, but I would
be surprised if I am the only person seeing this issue --- I'm using the
latest FileTree on github, so that could be the issue, since I don't
think the Pharo developers bother to keep the github repository
up-to-date ... I know they don't bother to submit pull requests to the
Metacello repository and AFAICT don't bother to even use the latest
version of Metacello ... ah well ... minor annoyances and if I'm the
only one seeing this issue, I can live with it:)

Dale

FFIGemstone64HandleType(Object)>>subclassResponsibility
FFIGemstone64HandleType(FFIExternalType)>>basicHandle:at:
FFIGemstone64HandleType(FFIExternalType)>>handle:at:
a subclass of FFITypeArray(FFIExternalArray)>>at:
GsGciClientForwarderSend>>performSendNoForwarder:
GsGciClientForwarderSend>>defaultAction
UndefinedObject>>handleSignal:
Context>>handleSignal:
Context>>handleSignal:
GsGciClientForwarderSend(Exception)>>signal
GsGci32xErrSType>>asLocalObjectFor:
GsGci32xErrSType>>asLocalObjectFor:ifNotConverted:
GsGciSession>>send:to:withArgs:
GsGciSession>>send:to:
GsGciClientForwarderTest>>testClientForwarderSend1
GsGciClientForwarderTest(TestCase)>>performTest
[ self setUp.
self performTest ] in GsGciClientForwarderTest(TestCase)>>runCase in
Block: [ self setUp....
BlockClosure>>ensure:
GsGciClientForwarderTest(TestCase)>>runCase
[ aTestCase announce: TestCaseStarted withResult: self.
aTestCase runCase.
aTestCase announce: TestCaseEnded withResult: self.
self addPass: aTestCase ] in TestResult>>runCaseForDebug: in Block: [
aTestCase announce: TestCaseStarted withResult: ...etc...
BlockClosure>>on:do:
TestResult>>runCaseForDebug:
[ result runCaseForDebug: self ] in
GsGciClientForwarderTest(TestCase)>>debug in Block: [ result
runCaseForDebug: self ]
BlockClosure>>ensure:
GsGciClientForwarderTest(TestCase)>>debug
[ :each |
each debug.
self announceTest: each.
self changed: each ] in [ self tests
     do: [ :each |
         each debug.
         self announceTest: each.
         self changed: each ] ] in TestSuite>>debug in Block: [ :each | ...
OrderedCollection>>do:
[ self tests
     do: [ :each |
         each debug.
         self announceTest: each.
         self changed: each ] ] in TestSuite>>debug in Block: [ self
tests...
BlockClosure>>ensure:
TestSuite>>debug

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [tode_st] FFIExternalType>>basicHandle:at: --- subclassResponsibility

Mariano Martinez Peck


On Mon, Apr 18, 2016 at 3:25 PM, Dale Henrichs <[hidden email]> wrote:
Mariano,

Next issue is that FFIExternalArray appears to not support #at: ... full stack is at end and this is based on commit c2201af.

This looks like a "know problem" because Damien Pollet has a checkin:

  Name: UnifiedFFI-DamienPollet.49
  Author: DamienPollet
  Time: 25 March 2016, 3:14:03.411979 pm
  UUID: 29783fc7-36b1-49ff-a10e-cbd24b6e2cd0
  Ancestors: UnifiedFFI-EstebanLorenzano.48

  Comments and attempt at FFIExternalStructure >> #basicHandleAt:put:

That looks like it is intended to address the issue, but Esteban has not incorporated it yet ...



That is interesting. Just for the record, did you try merging Damien's commit to see if it indeed solves the issue? that way I can ask esteban if he can merge/integrate that!

 
Again, I don't believe that this is a show stopper, since I'm pretty sure that I can extract the contents of the args via alternate, nefarious means ... would be nice to have as well .. as it is I'm going to have to spelunk around in the code looking for these "work arounds" and re-port GemStone-GCI once the UFFI work is completed ...

Sure, I agree to move forward even with nefarious means until UFFI supports what we need. 
 

Also it seems that I have to flush the cache on the Monticello Browser before I can trust the results of "Changes" ... I haven't searched the bugs (I don't have a fogbugz userid --- if that is still the system being used) and I haven't searched the mailing list either, but I would be surprised if I am the only person seeing this issue --- I'm using the latest FileTree on github, so that could be the issue, since I don't think the Pharo developers bother to keep the github repository up-to-date ... I know they don't bother to submit pull requests to the Metacello repository and AFAICT don't bother to even use the latest version of Metacello ... ah well ... minor annoyances and if I'm the only one seeing this issue, I can live with it:)


:(
What I can tell you, is that I have also had issues trusting the "Changes". But I don't remember if that was filetree/git or not...


 
Dale

FFIGemstone64HandleType(Object)>>subclassResponsibility
FFIGemstone64HandleType(FFIExternalType)>>basicHandle:at:
FFIGemstone64HandleType(FFIExternalType)>>handle:at:
a subclass of FFITypeArray(FFIExternalArray)>>at:
GsGciClientForwarderSend>>performSendNoForwarder:
GsGciClientForwarderSend>>defaultAction
UndefinedObject>>handleSignal:
Context>>handleSignal:
Context>>handleSignal:
GsGciClientForwarderSend(Exception)>>signal
GsGci32xErrSType>>asLocalObjectFor:
GsGci32xErrSType>>asLocalObjectFor:ifNotConverted:
GsGciSession>>send:to:withArgs:
GsGciSession>>send:to:
GsGciClientForwarderTest>>testClientForwarderSend1
GsGciClientForwarderTest(TestCase)>>performTest
[ self setUp.
self performTest ] in GsGciClientForwarderTest(TestCase)>>runCase in Block: [ self setUp....
BlockClosure>>ensure:
GsGciClientForwarderTest(TestCase)>>runCase
[ aTestCase announce: TestCaseStarted withResult: self.
aTestCase runCase.
aTestCase announce: TestCaseEnded withResult: self.
self addPass: aTestCase ] in TestResult>>runCaseForDebug: in Block: [ aTestCase announce: TestCaseStarted withResult: ...etc...
BlockClosure>>on:do:
TestResult>>runCaseForDebug:
[ result runCaseForDebug: self ] in GsGciClientForwarderTest(TestCase)>>debug in Block: [ result runCaseForDebug: self ]
BlockClosure>>ensure:
GsGciClientForwarderTest(TestCase)>>debug
[ :each |
each debug.
self announceTest: each.
self changed: each ] in [ self tests
    do: [ :each |
        each debug.
        self announceTest: each.
        self changed: each ] ] in TestSuite>>debug in Block: [ :each | ...
OrderedCollection>>do:
[ self tests
    do: [ :each |
        each debug.
        self announceTest: each.
        self changed: each ] ] in TestSuite>>debug in Block: [ self tests...
BlockClosure>>ensure:
TestSuite>>debug

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.



--

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [tode_st] FFIExternalType>>basicHandle:at: --- subclassResponsibility

Dale Henrichs-3


On 04/18/2016 11:29 AM, Mariano Martinez Peck wrote:


On Mon, Apr 18, 2016 at 3:25 PM, Dale Henrichs <[hidden email]> wrote:
Mariano,

Next issue is that FFIExternalArray appears to not support #at: ... full stack is at end and this is based on commit c2201af.

This looks like a "know problem" because Damien Pollet has a checkin:

  Name: UnifiedFFI-DamienPollet.49
  Author: DamienPollet
  Time: 25 March 2016, 3:14:03.411979 pm
  UUID: 29783fc7-36b1-49ff-a10e-cbd24b6e2cd0
  Ancestors: UnifiedFFI-EstebanLorenzano.48

  Comments and attempt at FFIExternalStructure >> #basicHandleAt:put:

That looks like it is intended to address the issue, but Esteban has not incorporated it yet ...



That is interesting. Just for the record, did you try merging Damien's commit to see if it indeed solves the issue? that way I can ask esteban if he can merge/integrate that!
I haven't tried merging ... if a workaround starts to get too involved, I will see if merging helps ...

 
Again, I don't believe that this is a show stopper, since I'm pretty sure that I can extract the contents of the args via alternate, nefarious means ... would be nice to have as well .. as it is I'm going to have to spelunk around in the code looking for these "work arounds" and re-port GemStone-GCI once the UFFI work is completed ...

Sure, I agree to move forward even with nefarious means until UFFI supports what we need. 
 

Also it seems that I have to flush the cache on the Monticello Browser before I can trust the results of "Changes" ... I haven't searched the bugs (I don't have a fogbugz userid --- if that is still the system being used) and I haven't searched the mailing list either, but I would be surprised if I am the only person seeing this issue --- I'm using the latest FileTree on github, so that could be the issue, since I don't think the Pharo developers bother to keep the github repository up-to-date ... I know they don't bother to submit pull requests to the Metacello repository and AFAICT don't bother to even use the latest version of Metacello ... ah well ... minor annoyances and if I'm the only one seeing this issue, I can live with it:)


:(
What I can tell you, is that I have also had issues trusting the "Changes". But I don't remember if that was filetree/git or not...


Okay at least I'm not the only one ... I also seem to be losing clicks a lot ... I've spent a lot of time in Pharo3.0 and Pharo4.0, so I've trained myself to double click in a pattern that "works" for Pharo3.0 and Pharo4.0, but does not work for Pharo5.0 as I end up trying to double click several times before I take a breath and either get it right or try an alternate method for "selecting all of the contents of a method pane" ... One thing I've learned is that double-clicking at the end of a comment will not select the whole comment as it did in previous versions of Pharo ... if I scroll to the top of the comment (and successfully find the beginning of the comment:) the double click does work there ... these happen with the big comments from gci.hr, which I'm using as comments in the ffi methods, so having to use extra scrolls is annoying ... but them I am not a UI expert and perhaps it's bad form to allow one to select all comment from the last position ... or I haven't learned to the right double click timing:)

Dale

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [tode_st] FFIExternalType>>basicHandle:at: --- subclassResponsibility

Tudor Girba-2
Hi,

> On Apr 18, 2016, at 8:42 PM, Dale Henrichs <[hidden email]> wrote:
>
>
>
> On 04/18/2016 11:29 AM, Mariano Martinez Peck wrote:
>>
>>
>> On Mon, Apr 18, 2016 at 3:25 PM, Dale Henrichs <[hidden email]> wrote:
>> Mariano,
>>
>> Next issue is that FFIExternalArray appears to not support #at: ... full stack is at end and this is based on commit c2201af.
>>
>> This looks like a "know problem" because Damien Pollet has a checkin:
>>
>>   Name: UnifiedFFI-DamienPollet.49
>>   Author: DamienPollet
>>   Time: 25 March 2016, 3:14:03.411979 pm
>>   UUID: 29783fc7-36b1-49ff-a10e-cbd24b6e2cd0
>>   Ancestors: UnifiedFFI-EstebanLorenzano.48
>>
>>   Comments and attempt at FFIExternalStructure >> #basicHandleAt:put:
>>
>> That looks like it is intended to address the issue, but Esteban has not incorporated it yet ...
>>
>>
>>
>> That is interesting. Just for the record, did you try merging Damien's commit to see if it indeed solves the issue? that way I can ask esteban if he can merge/integrate that!
> I haven't tried merging ... if a workaround starts to get too involved, I will see if merging helps ...
>>
>>  
>> Again, I don't believe that this is a show stopper, since I'm pretty sure that I can extract the contents of the args via alternate, nefarious means ... would be nice to have as well .. as it is I'm going to have to spelunk around in the code looking for these "work arounds" and re-port GemStone-GCI once the UFFI work is completed ...
>>
>> Sure, I agree to move forward even with nefarious means until UFFI supports what we need.
>>  
>>
>> Also it seems that I have to flush the cache on the Monticello Browser before I can trust the results of "Changes" ... I haven't searched the bugs (I don't have a fogbugz userid --- if that is still the system being used) and I haven't searched the mailing list either, but I would be surprised if I am the only person seeing this issue --- I'm using the latest FileTree on github, so that could be the issue, since I don't think the Pharo developers bother to keep the github repository up-to-date ... I know they don't bother to submit pull requests to the Metacello repository and AFAICT don't bother to even use the latest version of Metacello ... ah well ... minor annoyances and if I'm the only one seeing this issue, I can live with it:)
>>
>>
>> :(
>> What I can tell you, is that I have also had issues trusting the "Changes". But I don't remember if that was filetree/git or not...
>>
>
> Okay at least I'm not the only one ... I also seem to be losing clicks a lot ... I've spent a lot of time in Pharo3.0 and Pharo4.0, so I've trained myself to double click in a pattern that "works" for Pharo3.0 and Pharo4.0, but does not work for Pharo5.0 as I end up trying to double click several times before I take a breath and either get it right or try an alternate method for "selecting all of the contents of a method pane" ... One thing I've learned is that double-clicking at the end of a comment will not select the whole comment as it did in previous versions of Pharo ... if I scroll to the top of the comment (and successfully find the beginning of the comment:) the double click does work there ... these happen with the big comments from gci.hr, which I'm using as comments in the ffi methods, so having to use extra scrolls is annoying ... but them I am not a UI expert and perhaps it's bad form to allow one to select all comment from the last position ... or I haven't learned to the right double click timing:)

Double clicking at the end of a comment works exactly like double clicking at the beginning of a comment :).

However, indeed, with the recent introduction of Rubric, we now rely on double click like it is understood in any other application, instead of click-longpause-click like it was implemented in Morphic before.

Cheers,
Doru

> Dale
>
> --
> You received this message because you are subscribed to the Google Groups "tODE" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.

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

"Be rather willing to give than demanding to get."




--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [tode_st] FFIExternalType>>basicHandle:at: --- subclassResponsibility

Dale Henrichs-3


On 04/19/2016 07:13 AM, Tudor Girba wrote:

> Hi,
>
>> On Apr 18, 2016, at 8:42 PM, Dale Henrichs <[hidden email]> wrote:
>>
>>
>>
>> On 04/18/2016 11:29 AM, Mariano Martinez Peck wrote:
>>>
>>> On Mon, Apr 18, 2016 at 3:25 PM, Dale Henrichs <[hidden email]> wrote:
>>> Mariano,
>>>
>>> Next issue is that FFIExternalArray appears to not support #at: ... full stack is at end and this is based on commit c2201af.
>>>
>>> This looks like a "know problem" because Damien Pollet has a checkin:
>>>
>>>    Name: UnifiedFFI-DamienPollet.49
>>>    Author: DamienPollet
>>>    Time: 25 March 2016, 3:14:03.411979 pm
>>>    UUID: 29783fc7-36b1-49ff-a10e-cbd24b6e2cd0
>>>    Ancestors: UnifiedFFI-EstebanLorenzano.48
>>>
>>>    Comments and attempt at FFIExternalStructure >> #basicHandleAt:put:
>>>
>>> That looks like it is intended to address the issue, but Esteban has not incorporated it yet ...
>>>
>>>
>>>
>>> That is interesting. Just for the record, did you try merging Damien's commit to see if it indeed solves the issue? that way I can ask esteban if he can merge/integrate that!
>> I haven't tried merging ... if a workaround starts to get too involved, I will see if merging helps ...
>>>  
>>> Again, I don't believe that this is a show stopper, since I'm pretty sure that I can extract the contents of the args via alternate, nefarious means ... would be nice to have as well .. as it is I'm going to have to spelunk around in the code looking for these "work arounds" and re-port GemStone-GCI once the UFFI work is completed ...
>>>
>>> Sure, I agree to move forward even with nefarious means until UFFI supports what we need.
>>>  
>>>
>>> Also it seems that I have to flush the cache on the Monticello Browser before I can trust the results of "Changes" ... I haven't searched the bugs (I don't have a fogbugz userid --- if that is still the system being used) and I haven't searched the mailing list either, but I would be surprised if I am the only person seeing this issue --- I'm using the latest FileTree on github, so that could be the issue, since I don't think the Pharo developers bother to keep the github repository up-to-date ... I know they don't bother to submit pull requests to the Metacello repository and AFAICT don't bother to even use the latest version of Metacello ... ah well ... minor annoyances and if I'm the only one seeing this issue, I can live with it:)
>>>
>>>
>>> :(
>>> What I can tell you, is that I have also had issues trusting the "Changes". But I don't remember if that was filetree/git or not...
>>>
>> Okay at least I'm not the only one ... I also seem to be losing clicks a lot ... I've spent a lot of time in Pharo3.0 and Pharo4.0, so I've trained myself to double click in a pattern that "works" for Pharo3.0 and Pharo4.0, but does not work for Pharo5.0 as I end up trying to double click several times before I take a breath and either get it right or try an alternate method for "selecting all of the contents of a method pane" ... One thing I've learned is that double-clicking at the end of a comment will not select the whole comment as it did in previous versions of Pharo ... if I scroll to the top of the comment (and successfully find the beginning of the comment:) the double click does work there ... these happen with the big comments from gci.hr, which I'm using as comments in the ffi methods, so having to use extra scrolls is annoying ... but them I am not a UI expert and perhaps it's bad form to allow one to select all comment from the last position ... or I haven't learned to the right double click timing:)
> Double clicking at the end of a comment works exactly like double clicking at the beginning of a comment :).
>
> However, indeed, with the recent introduction of Rubric, we now rely on double click like it is understood in any other application, instead of click-longpause-click like it was implemented in Morphic before.
>
Ah and what is the pattern for "double click like it is understood in
any other application"? I pretty much double click in pharo only:)

Thanks for the tips ... I was almost thinking that there was a
processing delay involved in recognizing the double click ...

Dale

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [tode_st] FFIExternalType>>basicHandle:at: --- subclassResponsibility

Mariano Martinez Peck
Hi Dale,

Esteban told me he merged Damien's commit and for the other problem I opened an issue: https://pharo.fogbugz.com/f/cases/18029/ByteArray-unsignedLongLongAt-and-presumably-ByteArray-unsignedLongLongAt-put-wrong-for-UFFI

But he  told me that needs to be discussed with Eliot or the vm-dev mailing list. So this one will take a bit longer.

Will keep you informed. 

Thanks,


On Tue, Apr 19, 2016 at 1:18 PM, Dale Henrichs <[hidden email]> wrote:


On 04/19/2016 07:13 AM, Tudor Girba wrote:
Hi,

On Apr 18, 2016, at 8:42 PM, Dale Henrichs <[hidden email]> wrote:



On 04/18/2016 11:29 AM, Mariano Martinez Peck wrote:

On Mon, Apr 18, 2016 at 3:25 PM, Dale Henrichs <[hidden email]> wrote:
Mariano,

Next issue is that FFIExternalArray appears to not support #at: ... full stack is at end and this is based on commit c2201af.

This looks like a "know problem" because Damien Pollet has a checkin:

   Name: UnifiedFFI-DamienPollet.49
   Author: DamienPollet
   Time: 25 March 2016, 3:14:03.411979 pm
   UUID: 29783fc7-36b1-49ff-a10e-cbd24b6e2cd0
   Ancestors: UnifiedFFI-EstebanLorenzano.48

   Comments and attempt at FFIExternalStructure >> #basicHandleAt:put:

That looks like it is intended to address the issue, but Esteban has not incorporated it yet ...



That is interesting. Just for the record, did you try merging Damien's commit to see if it indeed solves the issue? that way I can ask esteban if he can merge/integrate that!
I haven't tried merging ... if a workaround starts to get too involved, I will see if merging helps ...
  Again, I don't believe that this is a show stopper, since I'm pretty sure that I can extract the contents of the args via alternate, nefarious means ... would be nice to have as well .. as it is I'm going to have to spelunk around in the code looking for these "work arounds" and re-port GemStone-GCI once the UFFI work is completed ...

Sure, I agree to move forward even with nefarious means until UFFI supports what we need.
 
Also it seems that I have to flush the cache on the Monticello Browser before I can trust the results of "Changes" ... I haven't searched the bugs (I don't have a fogbugz userid --- if that is still the system being used) and I haven't searched the mailing list either, but I would be surprised if I am the only person seeing this issue --- I'm using the latest FileTree on github, so that could be the issue, since I don't think the Pharo developers bother to keep the github repository up-to-date ... I know they don't bother to submit pull requests to the Metacello repository and AFAICT don't bother to even use the latest version of Metacello ... ah well ... minor annoyances and if I'm the only one seeing this issue, I can live with it:)


:(
What I can tell you, is that I have also had issues trusting the "Changes". But I don't remember if that was filetree/git or not...

Okay at least I'm not the only one ... I also seem to be losing clicks a lot ... I've spent a lot of time in Pharo3.0 and Pharo4.0, so I've trained myself to double click in a pattern that "works" for Pharo3.0 and Pharo4.0, but does not work for Pharo5.0 as I end up trying to double click several times before I take a breath and either get it right or try an alternate method for "selecting all of the contents of a method pane" ... One thing I've learned is that double-clicking at the end of a comment will not select the whole comment as it did in previous versions of Pharo ... if I scroll to the top of the comment (and successfully find the beginning of the comment:) the double click does work there ... these happen with the big comments from gci.hr, which I'm using as comments in the ffi methods, so having to use extra scrolls is annoying ... but them I am not a UI expert and perhaps it's bad form to allow one to select all comment from the last position ... or I haven't learned to the right double click timing:)
Double clicking at the end of a comment works exactly like double clicking at the beginning of a comment :).

However, indeed, with the recent introduction of Rubric, we now rely on double click like it is understood in any other application, instead of click-longpause-click like it was implemented in Morphic before.

Ah and what is the pattern for "double click like it is understood in any other application"? I pretty much double click in pharo only:)

Thanks for the tips ... I was almost thinking that there was a processing delay involved in recognizing the double click ...


Dale

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.



--

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [tode_st] FFIExternalType>>basicHandle:at: --- subclassResponsibility

Dale Henrichs-3
Excellent ... Thanks!

I'm using the "old way" and it is working.

Dale

On 4/20/16 5:17 AM, Mariano Martinez Peck wrote:
Hi Dale,

Esteban told me he merged Damien's commit and for the other problem I opened an issue: https://pharo.fogbugz.com/f/cases/18029/ByteArray-unsignedLongLongAt-and-presumably-ByteArray-unsignedLongLongAt-put-wrong-for-UFFI

But he  told me that needs to be discussed with Eliot or the vm-dev mailing list. So this one will take a bit longer.

Will keep you informed. 

Thanks,


On Tue, Apr 19, 2016 at 1:18 PM, Dale Henrichs <[hidden email]> wrote:


On 04/19/2016 07:13 AM, Tudor Girba wrote:
Hi,

On Apr 18, 2016, at 8:42 PM, Dale Henrichs <[hidden email]> wrote:



On 04/18/2016 11:29 AM, Mariano Martinez Peck wrote:

On Mon, Apr 18, 2016 at 3:25 PM, Dale Henrichs <[hidden email]> wrote:
Mariano,

Next issue is that FFIExternalArray appears to not support #at: ... full stack is at end and this is based on commit c2201af.

This looks like a "know problem" because Damien Pollet has a checkin:

   Name: UnifiedFFI-DamienPollet.49
   Author: DamienPollet
   Time: 25 March 2016, 3:14:03.411979 pm
   UUID: 29783fc7-36b1-49ff-a10e-cbd24b6e2cd0
   Ancestors: UnifiedFFI-EstebanLorenzano.48

   Comments and attempt at FFIExternalStructure >> #basicHandleAt:put:

That looks like it is intended to address the issue, but Esteban has not incorporated it yet ...



That is interesting. Just for the record, did you try merging Damien's commit to see if it indeed solves the issue? that way I can ask esteban if he can merge/integrate that!
I haven't tried merging ... if a workaround starts to get too involved, I will see if merging helps ...
  Again, I don't believe that this is a show stopper, since I'm pretty sure that I can extract the contents of the args via alternate, nefarious means ... would be nice to have as well .. as it is I'm going to have to spelunk around in the code looking for these "work arounds" and re-port GemStone-GCI once the UFFI work is completed ...

Sure, I agree to move forward even with nefarious means until UFFI supports what we need.
 
Also it seems that I have to flush the cache on the Monticello Browser before I can trust the results of "Changes" ... I haven't searched the bugs (I don't have a fogbugz userid --- if that is still the system being used) and I haven't searched the mailing list either, but I would be surprised if I am the only person seeing this issue --- I'm using the latest FileTree on github, so that could be the issue, since I don't think the Pharo developers bother to keep the github repository up-to-date ... I know they don't bother to submit pull requests to the Metacello repository and AFAICT don't bother to even use the latest version of Metacello ... ah well ... minor annoyances and if I'm the only one seeing this issue, I can live with it:)


:(
What I can tell you, is that I have also had issues trusting the "Changes". But I don't remember if that was filetree/git or not...

Okay at least I'm not the only one ... I also seem to be losing clicks a lot ... I've spent a lot of time in Pharo3.0 and Pharo4.0, so I've trained myself to double click in a pattern that "works" for Pharo3.0 and Pharo4.0, but does not work for Pharo5.0 as I end up trying to double click several times before I take a breath and either get it right or try an alternate method for "selecting all of the contents of a method pane" ... One thing I've learned is that double-clicking at the end of a comment will not select the whole comment as it did in previous versions of Pharo ... if I scroll to the top of the comment (and successfully find the beginning of the comment:) the double click does work there ... these happen with the big comments from gci.hr, which I'm using as comments in the ffi methods, so having to use extra scrolls is annoying ... but them I am not a UI expert and perhaps it's bad form to allow one to select all comment from the last position ... or I haven't learned to the right double click timing:)
Double clicking at the end of a comment works exactly like double clicking at the beginning of a comment :).

However, indeed, with the recent introduction of Rubric, we now rely on double click like it is understood in any other application, instead of click-longpause-click like it was implemented in Morphic before.

Ah and what is the pattern for "double click like it is understood in any other application"? I pretty much double click in pharo only:)

Thanks for the tips ... I was almost thinking that there was a processing delay involved in recognizing the double click ...


Dale

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.



--
--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [tode_st] FFIExternalType>>basicHandle:at: --- subclassResponsibility

Dale Henrichs-3
In reply to this post by Dale Henrichs-3


On 04/19/2016 09:18 AM, Dale Henrichs wrote:

>
> On 04/19/2016 07:13 AM, Tudor Girba wrote:
>> Double clicking at the end of a comment works exactly like double
>> clicking at the beginning of a comment :).
>>
>> However, indeed, with the recent introduction of Rubric, we now rely
>> on double click like it is understood in any other application,
>> instead of click-longpause-click like it was implemented in Morphic
>> before.
>>
> Ah and what is the pattern for "double click like it is understood in
> any other application"? I pretty much double click in pharo only:)
>
> Thanks for the tips ... I was almost thinking that there was a
> processing delay involved in recognizing the double click ...

Something I just noticed is that apparently I have to click in a window
to activate the window? Then a second click will adjust the location of
the cursor ... while I haven't tested this it's possble that my "double
click" habit assumed that I didn't need to activate the window first ...
so I have to train myself to triple click?

BTW, on linux I have things setup where putting the cursor in the window
activates the window so on linux at least I'm not in the habit of
clicking first ...

Still fumbling around .. BTW, I tried using CTL-a to select the entire
contents of pane (since my double clicking wasn't working) ... and even
though it isn't "documented in a menu" it seems to work in certain
circumstances and not others ... would be nice if it were "documented"
so that I could at least tell which windows it should work in and better
yet, would be that it worked everwhere:)

Dale

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [tode_st] FFIExternalType>>basicHandle:at: --- subclassResponsibility

Tudor Girba-2
Hi,

> On Apr 20, 2016, at 7:08 PM, Dale Henrichs <[hidden email]> wrote:
>
>
>
> On 04/19/2016 09:18 AM, Dale Henrichs wrote:
>>
>> On 04/19/2016 07:13 AM, Tudor Girba wrote:
>>> Double clicking at the end of a comment works exactly like double clicking at the beginning of a comment :).
>>>
>>> However, indeed, with the recent introduction of Rubric, we now rely on double click like it is understood in any other application, instead of click-longpause-click like it was implemented in Morphic before.
>>>
>> Ah and what is the pattern for "double click like it is understood in any other application"? I pretty much double click in pharo only:)
>>
>> Thanks for the tips ... I was almost thinking that there was a processing delay involved in recognizing the double click ...
>
> Something I just noticed is that apparently I have to click in a window to activate the window? Then a second click will adjust the location of the cursor ... while I haven't tested this it's possble that my "double click" habit assumed that I didn't need to activate the window first ... so I have to train myself to triple click?
>
> BTW, on linux I have things setup where putting the cursor in the window activates the window so on linux at least I'm not in the habit of clicking first ...
>
> Still fumbling around .. BTW, I tried using CTL-a to select the entire contents of pane (since my double clicking wasn't working) ... and even though it isn't "documented in a menu" it seems to work in certain circumstances and not others ... would be nice if it were "documented" so that I could at least tell which windows it should work in and better yet, would be that it worked everwhere:)

On which platform are you?

Cheers,
Doru



> Dale
>
> --
> You received this message because you are subscribed to the Google Groups "tODE" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.

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

"From an abstract enough point of view, any two things are similar."




--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [tode_st] FFIExternalType>>basicHandle:at: --- subclassResponsibility

Dale Henrichs-3


On 4/21/16 2:59 AM, Tudor Girba wrote:

> Hi,
>
>> On Apr 20, 2016, at 7:08 PM, Dale Henrichs <[hidden email]> wrote:
>>
>>
>>
>> On 04/19/2016 09:18 AM, Dale Henrichs wrote:
>>> On 04/19/2016 07:13 AM, Tudor Girba wrote:
>>>> Double clicking at the end of a comment works exactly like double clicking at the beginning of a comment :).
>>>>
>>>> However, indeed, with the recent introduction of Rubric, we now rely on double click like it is understood in any other application, instead of click-longpause-click like it was implemented in Morphic before.
>>>>
>>> Ah and what is the pattern for "double click like it is understood in any other application"? I pretty much double click in pharo only:)
>>>
>>> Thanks for the tips ... I was almost thinking that there was a processing delay involved in recognizing the double click ...
>> Something I just noticed is that apparently I have to click in a window to activate the window? Then a second click will adjust the location of the cursor ... while I haven't tested this it's possble that my "double click" habit assumed that I didn't need to activate the window first ... so I have to train myself to triple click?
>>
>> BTW, on linux I have things setup where putting the cursor in the window activates the window so on linux at least I'm not in the habit of clicking first ...
>>
>> Still fumbling around .. BTW, I tried using CTL-a to select the entire contents of pane (since my double clicking wasn't working) ... and even though it isn't "documented in a menu" it seems to work in certain circumstances and not others ... would be nice if it were "documented" so that I could at least tell which windows it should work in and better yet, would be that it worked everwhere:)
> On which platform are you?
>
> Cheers,
> Doru
I work on an OSX laptop (Yosemite) and an Ubuntu 14.04 desktop - and yes
sometimes I get the CTL/ALT keys mixed up as I move back and forth
between computers, but in the CTL-a (or ALT-a) case I at least used the
came modifier key in both cases:)

I also occasionally us the X Windows app where you do use CTL-* on the
Mac and I recall a recent session where I was using Pharo over X Windows
to my desktop where I just quit, because certain shortcut keys were not
working correctly - something to do with basic cut/copy/paste failures
--- FWIW I "blame" the X Windows app for that problem:)

Dale

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.