[Pharo-dev] GTDebugger variables table

[Denis Kudriashov]

Hi.

Finally I force myself to report my bad feeling of merged variable table in
GTDebugger.
By "merged" I mean that debugger join temps and receiver state in one table.
Sometimes I really not like it because it is difficult to find concrete
variable.

Now I think I realized main reason of my confusion. Temps and receiver vars
are not just in single table but they are also sorted by name all together.

For example try debug #expandBy: method:

(1@2 corner: 3@4) expandBy: 10

You will see rows: self, corner, delta, origin, thisContext, stackTop
Maybe in this example it is not really bad. But it shows problem.
And imaging that there are much more inst vars in receiver object like in
morph or Spec. It is really difficult to find desired temp.
Actually it is also difficult to find inst var which are really used in
selected method. And usually methods use only few variables and few temps.
And the rest variables in table are just waste.

I think we can improve this part of debugger. My idea that variable table
should show only used temp and variables. And "self" should be selected by
default.
With this main table will show only important information. And on the right
pane we will see receiver state like in the old debuggers.

What you think?

Re: [Pharo-dev] GTDebugger variables table

[Nicolas Anquetil]

for what it is worth, Eclipse behaves more or less as described by Denis:

you see only local variables (self being one) and if a variable contains 
an object (such as self), it expands in a three to show the attributes 
of this object.


I sometimes find it a pain to have to expand "self" to see the 
attributes, but it is true that when there are many attributes/local 
variables, one gets easily annoyed too.


nicolas


On 02/02/2017 11:22, Denis Kudriashov wrote:

Hi.

Finally I force myself to report my bad feeling of merged variable 
table in GTDebugger.
By "merged" I mean that debugger join temps and receiver state in one 
table.
Sometimes I really not like it because it is difficult to find 
concrete variable.


Now I think I realized main reason of my confusion. Temps and receiver 
vars are not just in single table but they are also sorted by name all 
together.


For example try debug #expandBy: method:

(1@2 corner: 3@4) expandBy: 10

You will see rows: self, corner, delta, origin, thisContext, stackTop
Maybe in this example it is not really bad. But it shows problem.
And imaging that there are much more inst vars in receiver object like 
in morph or Spec. It is really difficult to find desired temp.
Actually it is also difficult to find inst var which are really used 
in selected method. And usually methods use only few variables and few 
temps. And the rest variables in table are just waste.


I think we can improve this part of debugger. My idea that variable 
table should show only used temp and variables. And "self" should be 
selected by default.
With this main table will show only important information. And on the 
right pane we will see receiver state like in the old debuggers.


What you think?



--
Nicolas Anquetil -- MCF (HDR)
Project-Team RMod

Re: [Pharo-dev] GTDebugger variables table

[Ben Coman]

> On 02/02/2017 11:22, Denis Kudriashov wrote:
>
> Hi.
>
> Finally I force myself to report my bad feeling of merged variable table in
> GTDebugger.
> By "merged" I mean that debugger join temps and receiver state in one table.
> Sometimes I really not like it because it is difficult to find concrete
> variable.
>
> Now I think I realized main reason of my confusion. Temps and receiver vars
> are not just in single table but they are also sorted by name all together.
>
> For example try debug #expandBy: method:
>
> (1@2 corner: 3@4) expandBy: 10
>
> You will see rows: self, corner, delta, origin, thisContext, stackTop
> Maybe in this example it is not really bad. But it shows problem.
> And imaging that there are much more inst vars in receiver object like in
> morph or Spec. It is really difficult to find desired temp.
> Actually it is also difficult to find inst var which are really used in
> selected method. And usually methods use only few variables and few temps.
> And the rest variables in table are just waste.
>
> I think we can improve this part of debugger. My idea that variable table
> should show only used temp and variables. And "self" should be selected by
> default.
> With this main table will show only important information. And on the right
> pane we will see receiver state like in the old debuggers.
>
> What you think?

I think thats a really innovative approach.  I've haven't been too
bothered by this, but I imagine it would feel like an improvement.
I'd like to try it.

On Thu, Feb 2, 2017 at 7:00 PM, Nicolas Anquetil
 wrote:
> for what it is worth, Eclipse behaves more or less as described by Denis:
>
> you see only local variables (self being one) and if a variable contains an
> object (such as self), it expands in a three to show the attributes of this
> object.

in a tree?

>
> I sometimes find it a pain to have to expand "self" to see the attributes,

but in this case it would be pre-selected and already showing in the second pane
cheers -ben

> but it is true that when there are many attributes/local variables, one gets
> easily annoyed too.

Re: [Pharo-dev] Pharo 6 update catalog entries

[Serge Stinckwich]

I update PolyMath for Pharo 6.0.
All tests are green: https://github.com/PolyMathOrg/PolyMath

On Tue, Jan 31, 2017 at 10:44 AM, Torsten Bergmann  wrote:
> Hi,
>
> in preparation of upcoming Pharo 6 release we already should do a pass on
> all our external loadable projects:
>
>  - load them into Pharo 6 to see if they could be loaded cleanly
>(due to automatic transformation of deprecated messages your packages
> get dirty when converted)
>  - check if they are already/still working in Pharo 6 by using them
>  - check that the tests are running in Pharo 6
>  - check that we have a proper config with catalog methods and
>that the latest config is in the MetaRepoForPharo60 repository
>http://smalltalkhub.com/#!/~Pharo/MetaRepoForPharo60
>
> I did a pass over most projects I implemented or contributed to
> and we now have much more Pharo 6 based projects in catalog:
>
>  - Units, Artefact
>  - EventRecorder, Bugzilla, PunQlite, HubCap, VistaCursors, INIFile
>  - Pomodoro, DesktopManager, QuickAccess, WebBrowser, MessageFlowBrowser
>  - ScriptManager (now with icons)
>  - Tealight, Teapot, Nginx, NPMJS, GitHubAPI, FogBugz
>  - OSWindows, OSOSX, OSUnix, OSLinuxCentOS, OSLinuxUbuntu, OSRaspbian
>  - ...
>
> You should do the same with your projects!
>
> Also if you have a project on SqueakSource, STHub or GitHub that
> is not yet in the catalog it would be good to provide a ConfigurationOf...
> with a catalog description. Using Versionner it is easy to create one
> or generate the required catalog methods.
>
> This would give more visibility to your projects!
>
> Thanks
> T.
>



-- 
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/

[Pharo-dev] Zinc / REST misunderstanding

[Nicolas Anquetil]

Hi,

I am trying to create a small Redmine wrapper with Zinc, using Redmine 
REST API


And I am having a problem to update issues in redmine from zinc.
In curl, I can do:

curl -v -H "Content-Type: application/json" -X PUT --data-binary '{
  "issue": {
"subject": "Subject different changed",
"notes": "The subject was changed changed"
  }
}'  -u anquetil: http:///redmine/issues/430.json

and this updates issue #430 by changing its subject and notes.

For information, the trace given by curl (-v) is:

*   Trying ...
  % Total% Received % Xferd  Average Speed   Time Time Time  
Current

 Dload  Upload   Total SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- 
--:--:-- 0* Connected to  () port 80 (#0)

* Server auth using Basic with user 'anquetil'
> PUT /redmine/issues/430.json HTTP/1.1
> Host: 
> Authorization: Basic YW5xdWV0aWw6UjNkTTFuMy1wYXNz
> User-Agent: curl/7.47.0
> Accept: */*
> Content-Type: application/json
> Content-Length: 110
>
} [110 bytes data]
* upload completely sent off: 110 out of 110 bytes
100   1100 0  100   110  0546 --:--:-- --:--:-- 
--:--:--   544< HTTP/1.1 200 OK

< Date: Thu, 02 Feb 2017 12:18:41 GMT
< Server: Apache/2.2.22 (Ubuntu)
< X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.21
< X-Rack-Cache: invalidate, pass
< X-Request-Id: 73f75565...
< X-UA-Compatible: IE=Edge,chrome=1
< Cache-Control: no-cache
< X-Runtime: 0.994081
< Set-Cookie: _redmine_session=BAh7ByIP...; path=/; HttpOnly
< Set-Cookie: autologin=; path=/; expires=Thu, 01-Jan-1970 00:00:00 GMT
< Status: 200
< Content-Length: 0
< Content-Type: application/json; charset=utf-8
<
100   1100 0  100   110  0105  0:00:01 0:00:01 
--:--:--   105

* Connection #0 to host  left intact

The problem is that I cannot replicate that with Zinc:

cont := '{
  "issue": {
"subject": "Subject different changed",
"notes": "The subject was changed changed"
  }
}'.
ent := ((ZnHeaders requestHeadersFor: 'http:///redmine/' 
asZnUrl )

contentType: (ZnMimeType main: 'application' sub: 'json')) ;
contentLength: cont size.

ZnClient new
beOneShot ;
entity: ent ;
username: 'anquetil' password: '' ;
put: 'http:///redmine/issues/430.json' contents: cont ;
response.

if I inspect the ZnHeader constructed, it seems to have all headers that 
curl traces except the Authorization: Basic one:


The response of ZnClient is "200 OK", with again the same headers as 
reported by curl


Yet the issue remains unchanged on the redmine server (contrary to curl 
evidently)


Can anyone explain where the error could be ?
Any help will be gladly welcome

nicolas

--
Nicolas Anquetil -- MCF (HDR)
Project-Team RMod

Re: [Pharo-dev] Zinc / REST misunderstanding

[Sven Van Caekenberghe]

> On 2 Feb 2017, at 16:51, Nicolas Anquetil  wrote:
> 
> 
> Hi,
> 
> I am trying to create a small Redmine wrapper with Zinc, using Redmine REST 
> API
> 
> And I am having a problem to update issues in redmine from zinc.
> In curl, I can do:
> 
> curl -v -H "Content-Type: application/json" -X PUT --data-binary '{
>   "issue": {
> "subject": "Subject different changed",
> "notes": "The subject was changed changed" 
>   }
> }'  -u anquetil: http:///redmine/issues/430.json
> and this updates issue #430 by changing its subject and notes.
> 
> For information, the trace given by curl (-v) is:
> 
> *   Trying ...
>   % Total% Received % Xferd  Average Speed   TimeTime Time  
> Current
>  Dload  Upload   Total   SpentLeft  Speed
>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 
> 0* Connected to  () port 80 (#0)
> * Server auth using Basic with user 'anquetil'
> > PUT /redmine/issues/430.json HTTP/1.1
> > Host: 
> > Authorization: Basic YW5xdWV0aWw6UjNkTTFuMy1wYXNz
> > User-Agent: curl/7.47.0
> > Accept: */*
> > Content-Type: application/json
> > Content-Length: 110
> > 
> } [110 bytes data]
> * upload completely sent off: 110 out of 110 bytes
> 100   1100 0  100   110  0546 --:--:-- --:--:-- --:--:--   
> 544< HTTP/1.1 200 OK
> < Date: Thu, 02 Feb 2017 12:18:41 GMT
> < Server: Apache/2.2.22 (Ubuntu)
> < X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.21
> < X-Rack-Cache: invalidate, pass
> < X-Request-Id: 73f75565...
> < X-UA-Compatible: IE=Edge,chrome=1
> < Cache-Control: no-cache
> < X-Runtime: 0.994081
> < Set-Cookie: _redmine_session=BAh7ByIP...; path=/; HttpOnly
> < Set-Cookie: autologin=; path=/; expires=Thu, 01-Jan-1970 00:00:00 GMT
> < Status: 200
> < Content-Length: 0
> < Content-Type: application/json; charset=utf-8
> < 
> 100   1100 0  100   110  0105  0:00:01  0:00:01 --:--:--   105
> * Connection #0 to host  left intact
> The problem is that I cannot replicate that with Zinc:
> 
> cont := '{
>   "issue": {
> "subject": "Subject different changed",
> "notes": "The subject was changed changed" 
>   }
> }'.
> ent := ((ZnHeaders requestHeadersFor: 'http:///redmine/' asZnUrl )
> contentType: (ZnMimeType main: 'application' sub: 'json')) ;
> contentLength: cont size.
> 
> ZnClient new 
> beOneShot ;
> entity: ent ;
> username: 'anquetil' password: '' ;
> put: 'http:///redmine/issues/430.json' contents: cont ;
> response.

You are doing something double (ent & cont are the same). Also, I usually start 
by setting the URL and continue from there. Could you try:

ZnClient new 
beOneShot ;
url: 'http:///redmine/issues/430.json' ;
entity: ent ;
username: 'anquetil' password: '' ;
put ;
yourself.

I would inspect the instance so you can see both the request and response.

Does this work ?

Also, the JSON can be generated from objects instead of being written as a 
string, but you knew that, right ?

> if I inspect the ZnHeader constructed, it seems to have all headers that curl 
> traces except the Authorization: Basic one:
> 
> 
> 
> The response of ZnClient is "200 OK", with again the same headers as reported 
> by curl
> 
> 
> 
> Yet the issue remains unchanged on the redmine server (contrary to curl 
> evidently)
> 
> Can anyone explain where the error could be ?
> Any help will be gladly welcome
> 
> nicolas
> 
> -- 
> Nicolas Anquetil -- MCF (HDR)
> Project-Team RMod
> 

Re: [Pharo-dev] GTDebugger variables table

[John Brant]

On 02/02/2017 04:22 AM, Denis Kudriashov wrote:


Now I think I realized main reason of my confusion. Temps and receiver
vars are not just in single table but they are also sorted by name all
together.


I'm not a fan of this either. While I can filter by the type of variable 
to limit the list, the next time I step the debugger, the whole list 
resets. The list filter and selection should be kept across steps in the 
debugger (if possible).


Some might argue that you should have fewer variables so the list would 
be easier to use in the debugger. However, if you are using the 
debugger, likely you are still in the "make it work" phase and haven't 
performed the factoring from the "make it right" phase.




I think we can improve this part of debugger. My idea that variable
table should show only used temp and variables. And "self" should be
selected by default.
With this main table will show only important information. And on the
right pane we will see receiver state like in the old debuggers.

What you think?


I think my preference would be to have several tabs for the variables. 
In addition to the one tab that we have now that shows all variables, I 
can think of tabs for locals, inst vars, interesting variables, watched 
variables/expressions, and stack variables. Locals would show just the 
method/block arguments and any temps defined in the method. Inst vars 
would show the object's inst vars (and maybe class vars, however these 
would only appear after the inst vars).


Interesting variables would show locals and inst vars used by the 
method. The locals would be limited to the ones that are still active at 
the current location in the method. For example, if you are in a block, 
it would only show variables used in the block. Also, if you are 
before(/after) the first(/final) use of the variable, it wouldn't show 
in the interesting list. Interesting variables should also do some 
analysis to see what accessor methods are used and show their 
corresponding variables.


Watched variables/expressions would be user controlled. The user could 
add/remove variables or expressions. These variables/expressions would 
remain across different methods. If a variable didn't exist in the other 
method, "Invalid" could be displayed.


Finally, stack variables would display the whole stack and not just the 
top item. I like the ability to see the stack top, but it really doesn't 
work if you want to see the first argument of a two argument message 
send. For example, if you debug "Array with: OrderedCollection new with: 
Set new", stepping over the "OrderedCollection new" immediately pushes 
the "Set" class on the stack so you can't see the "OrderedCollection 
new" object.



BTW, the current variable list sometimes shows 'error obtaining field 
value' for temporaries when stepping through a method. I'm not sure why 
it occurs, but it should always be able to display the temp variables.



John Brant

Re: [Pharo-dev] Pharo 6 update catalog entries

[Sven Van Caekenberghe]

Good idea, Torsten!

I updated the following (with new #stable releases and catalog configs for 
Pharo 3,4,5 & 6):

- NeoCSV
- NeoJSON
- Ston
- ZTimestamp
- Stamp
- ZincHTTPComponents
- Zodiac
- WebSockets
- Zinc SSO

These were already running 6.0 builds on the CI servers.

Sven

> On 31 Jan 2017, at 10:44, Torsten Bergmann  wrote:
> 
> Hi,
> 
> in preparation of upcoming Pharo 6 release we already should do a pass on 
> all our external loadable projects:
> 
> - load them into Pharo 6 to see if they could be loaded cleanly 
>   (due to automatic transformation of deprecated messages your packages
>get dirty when converted)
> - check if they are already/still working in Pharo 6 by using them
> - check that the tests are running in Pharo 6
> - check that we have a proper config with catalog methods and
>   that the latest config is in the MetaRepoForPharo60 repository
>   http://smalltalkhub.com/#!/~Pharo/MetaRepoForPharo60
> 
> I did a pass over most projects I implemented or contributed to
> and we now have much more Pharo 6 based projects in catalog:
> 
> - Units, Artefact
> - EventRecorder, Bugzilla, PunQlite, HubCap, VistaCursors, INIFile 
> - Pomodoro, DesktopManager, QuickAccess, WebBrowser, MessageFlowBrowser
> - ScriptManager (now with icons) 
> - Tealight, Teapot, Nginx, NPMJS, GitHubAPI, FogBugz
> - OSWindows, OSOSX, OSUnix, OSLinuxCentOS, OSLinuxUbuntu, OSRaspbian
> - ...
> 
> You should do the same with your projects! 
> 
> Also if you have a project on SqueakSource, STHub or GitHub that
> is not yet in the catalog it would be good to provide a ConfigurationOf...
> with a catalog description. Using Versionner it is easy to create one
> or generate the required catalog methods. 
> 
> This would give more visibility to your projects!
> 
> Thanks
> T.
> 

Re: [Pharo-dev] GTDebugger variables table

[Denis Kudriashov]

2017-02-02 17:16 GMT+01:00 John Brant :

> I think my preference would be to have several tabs for the variables. In
> addition to the one tab that we have now that shows all variables, I can
> think of tabs for locals, inst vars, interesting variables, watched
> variables/expressions, and stack variables. Locals would show just the
> method/block arguments and any temps defined in the method. Inst vars would
> show the object's inst vars (and maybe class vars, however these would only
> appear after the inst vars).
>
> Interesting variables would show locals and inst vars used by the method.
> The locals would be limited to the ones that are still active at the
> current location in the method. For example, if you are in a block, it
> would only show variables used in the block. Also, if you are
> before(/after) the first(/final) use of the variable, it wouldn't show in
> the interesting list. Interesting variables should also do some analysis to
> see what accessor methods are used and show their corresponding variables.
>
> Watched variables/expressions would be user controlled. The user could
> add/remove variables or expressions. These variables/expressions would
> remain across different methods. If a variable didn't exist in the other
> method, "Invalid" could be displayed.
>
> Finally, stack variables would display the whole stack and not just the
> top item. I like the ability to see the stack top, but it really doesn't
> work if you want to see the first argument of a two argument message send.
> For example, if you debug "Array with: OrderedCollection new with: Set
> new", stepping over the "OrderedCollection new" immediately pushes the
> "Set" class on the stack so you can't see the "OrderedCollection new"
> object.
>
>
> BTW, the current variable list sometimes shows 'error obtaining field
> value' for temporaries when stepping through a method. I'm not sure why it
> occurs, but it should always be able to display the temp variables.
>

I want everything you suggest :)

Re: [Pharo-dev] Zinc / REST misunderstanding

[Nicolas Anquetil]

Hi

thanks Sven, it now works.

from your answer, I could infer the final solution. Apart from your 
suggestions, the content-type: also had to be called on ZnClient and voila!


nicolas


On 02/02/2017 17:11, Sven Van Caekenberghe wrote:

On 2 Feb 2017, at 16:51, Nicolas Anquetil  wrote:


Hi,

I am trying to create a small Redmine wrapper with Zinc, using Redmine REST API

And I am having a problem to update issues in redmine from zinc.
In curl, I can do:

curl -v -H "Content-Type: application/json" -X PUT --data-binary '{
   "issue": {
 "subject": "Subject different changed",
 "notes": "The subject was changed changed"
   }
}'  -u anquetil: http:///redmine/issues/430.json
and this updates issue #430 by changing its subject and notes.

For information, the trace given by curl (-v) is:

*   Trying ...
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0* Connected 
to  () port 80 (#0)
* Server auth using Basic with user 'anquetil'

PUT /redmine/issues/430.json HTTP/1.1
Host: 
Authorization: Basic YW5xdWV0aWw6UjNkTTFuMy1wYXNz
User-Agent: curl/7.47.0
Accept: */*
Content-Type: application/json
Content-Length: 110


} [110 bytes data]
* upload completely sent off: 110 out of 110 bytes
100   1100 0  100   110  0546 --:--:-- --:--:-- --:--:--   544< 
HTTP/1.1 200 OK
< Date: Thu, 02 Feb 2017 12:18:41 GMT
< Server: Apache/2.2.22 (Ubuntu)
< X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.21
< X-Rack-Cache: invalidate, pass
< X-Request-Id: 73f75565...
< X-UA-Compatible: IE=Edge,chrome=1
< Cache-Control: no-cache
< X-Runtime: 0.994081
< Set-Cookie: _redmine_session=BAh7ByIP...; path=/; HttpOnly
< Set-Cookie: autologin=; path=/; expires=Thu, 01-Jan-1970 00:00:00 GMT
< Status: 200
< Content-Length: 0
< Content-Type: application/json; charset=utf-8
<
100   1100 0  100   110  0105  0:00:01  0:00:01 --:--:--   105
* Connection #0 to host  left intact
The problem is that I cannot replicate that with Zinc:

cont := '{
   "issue": {
 "subject": "Subject different changed",
 "notes": "The subject was changed changed"
   }
}'.
ent := ((ZnHeaders requestHeadersFor: 'http:///redmine/' asZnUrl )
 contentType: (ZnMimeType main: 'application' sub: 'json')) ;
 contentLength: cont size.
 
ZnClient new

 beOneShot ;
 entity: ent ;
 username: 'anquetil' password: '' ;
 put: 'http:///redmine/issues/430.json' contents: cont ;
 response.

You are doing something double (ent & cont are the same). Also, I usually start 
by setting the URL and continue from there. Could you try:

ZnClient new
 beOneShot ;
 url: 'http:///redmine/issues/430.json' ;
 entity: ent ;
 username: 'anquetil' password: '' ;
 put ;
 yourself.

I would inspect the instance so you can see both the request and response.

Does this work ?

Also, the JSON can be generated from objects instead of being written as a 
string, but you knew that, right ?


if I inspect the ZnHeader constructed, it seems to have all headers that curl 
traces except the Authorization: Basic one:



The response of ZnClient is "200 OK", with again the same headers as reported 
by curl



Yet the issue remains unchanged on the redmine server (contrary to curl 
evidently)

Can anyone explain where the error could be ?
Any help will be gladly welcome

nicolas

--
Nicolas Anquetil -- MCF (HDR)
Project-Team RMod





--
Nicolas Anquetil -- MCF (HDR)
Project-Team RMod

Re: [Pharo-dev] Zinc / REST misunderstanding

[Sven Van Caekenberghe]

Well, now that it works, we can make it better ;-)

This is a more correct way to do your call:

ZnClient new
  beOneShot;
  contentWriter: [ :data | ZnEntity 
with: (STONJSON toString: data ) 
type: ZnMimeType applicationJson ];
  url: 'http://server.com/redmine/issues/430.json';
  username: 'anquetil' password: '';
  contents: { #issue -> { 
#subject -> 'Subject different changed'. 
#notes -> 'The subject was changed changed' } asDictionary } asDictionary;
  put.

It is all in one expression now, but there normally is a common configuration 
part for the ZnClient, and then a part that is different for each call. 
#contentWriter: is part of the configuration, while #contents: is your data. 
The content writer takes your data in as objects and turns it into a typed 
entity. (There is also a corresponding #contentReader: that you can use to 
parse JSON coming back, if necessary).

Sven

> On 2 Feb 2017, at 17:31, Nicolas Anquetil  wrote:
> 
> 
> Hi
> 
> thanks Sven, it now works.
> 
> from your answer, I could infer the final solution. Apart from your 
> suggestions, the content-type: also had to be called on ZnClient and voila!
> 
> nicolas
> 
> 
> On 02/02/2017 17:11, Sven Van Caekenberghe wrote:
>>> On 2 Feb 2017, at 16:51, Nicolas Anquetil  wrote:
>>> 
>>> 
>>> Hi,
>>> 
>>> I am trying to create a small Redmine wrapper with Zinc, using Redmine REST 
>>> API
>>> 
>>> And I am having a problem to update issues in redmine from zinc.
>>> In curl, I can do:
>>> 
>>> curl -v -H "Content-Type: application/json" -X PUT --data-binary '{
>>>   "issue": {
>>> "subject": "Subject different changed",
>>> "notes": "The subject was changed changed"
>>>   }
>>> }'  -u anquetil: http:///redmine/issues/430.json
>>> and this updates issue #430 by changing its subject and notes.
>>> 
>>> For information, the trace given by curl (-v) is:
>>> 
>>> *   Trying ...
>>>   % Total% Received % Xferd  Average Speed   TimeTime Time  
>>> Current
>>>  Dload  Upload   Total   SpentLeft  
>>> Speed
>>>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
>>>  0* Connected to  () port 80 (#0)
>>> * Server auth using Basic with user 'anquetil'
 PUT /redmine/issues/430.json HTTP/1.1
 Host: 
 Authorization: Basic YW5xdWV0aWw6UjNkTTFuMy1wYXNz
 User-Agent: curl/7.47.0
 Accept: */*
 Content-Type: application/json
 Content-Length: 110
 
>>> } [110 bytes data]
>>> * upload completely sent off: 110 out of 110 bytes
>>> 100   1100 0  100   110  0546 --:--:-- --:--:-- --:--:--   
>>> 544< HTTP/1.1 200 OK
>>> < Date: Thu, 02 Feb 2017 12:18:41 GMT
>>> < Server: Apache/2.2.22 (Ubuntu)
>>> < X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.21
>>> < X-Rack-Cache: invalidate, pass
>>> < X-Request-Id: 73f75565...
>>> < X-UA-Compatible: IE=Edge,chrome=1
>>> < Cache-Control: no-cache
>>> < X-Runtime: 0.994081
>>> < Set-Cookie: _redmine_session=BAh7ByIP...; path=/; HttpOnly
>>> < Set-Cookie: autologin=; path=/; expires=Thu, 01-Jan-1970 00:00:00 GMT
>>> < Status: 200
>>> < Content-Length: 0
>>> < Content-Type: application/json; charset=utf-8
>>> <
>>> 100   1100 0  100   110  0105  0:00:01  0:00:01 --:--:--   
>>> 105
>>> * Connection #0 to host  left intact
>>> The problem is that I cannot replicate that with Zinc:
>>> 
>>> cont := '{
>>>   "issue": {
>>> "subject": "Subject different changed",
>>> "notes": "The subject was changed changed"
>>>   }
>>> }'.
>>> ent := ((ZnHeaders requestHeadersFor: 'http:///redmine/' asZnUrl 
>>> )
>>> contentType: (ZnMimeType main: 'application' sub: 'json')) ;
>>> contentLength: cont size.
>>> ZnClient new
>>> beOneShot ;
>>> entity: ent ;
>>> username: 'anquetil' password: '' ;
>>> put: 'http:///redmine/issues/430.json' contents: cont ;
>>> response.
>> You are doing something double (ent & cont are the same). Also, I usually 
>> start by setting the URL and continue from there. Could you try:
>> 
>> ZnClient new
>> beOneShot ;
>> url: 'http:///redmine/issues/430.json' ;
>> entity: ent ;
>> username: 'anquetil' password: '' ;
>> put ;
>> yourself.
>> 
>> I would inspect the instance so you can see both the request and response.
>> 
>> Does this work ?
>> 
>> Also, the JSON can be generated from objects instead of being written as a 
>> string, but you knew that, right ?
>> 
>>> if I inspect the ZnHeader constructed, it seems to have all headers that 
>>> curl traces except the Authorization: Basic one:
>>> 
>>> 
>>> 
>>> The response of ZnClient is "200 OK", with again the same headers as 
>>> reported by curl
>>> 
>>> 
>>> 
>>> Yet the issue remains unchanged on the redmine server (contrary to curl 
>>> evidently)
>>> 
>>> Can anyone explain where the error could be ?
>>> Any help will be gladly welcome
>>> 
>>> nicolas
>>> 
>>> -- 
>>> Nicolas Anquetil -- MCF (HDR)
>>> Project-Team RMod
>>> 

Re: [Pharo-dev] athens dead code?

[Igor Stasenko]

On 29 January 2017 at 19:16, stepharong  wrote:

> On Sun, 29 Jan 2017 17:21:44 +0100, Igor Stasenko 
> wrote:
>
>
>
> On 29 January 2017 at 16:16, stepharong  wrote:
>
>>
>>
>> On 27 January 2017 at 00:06, stepharong  wrote:
>>
>>>
>>> Yes because it if keep dead code around we will have a broken house
>> window syndrome and I do not like it.
>>
>
> You don't have to advocate that to me. I am fully on your side with this :)
>
> excellent!
>
> Can you propose a slice so that we fix the code?
>

Right now i can only propose if someone else propose the slice..
I don't have much free time on doing things on the side, even if i would
like to do it...
I am not the God, and as you know already , my brains working well only if
they are in single-threaded mode :)



-- 
Best regards,
Igor Stasenko.

[Pharo-dev] magic numbers in gtInspectorVariableValuePairs

[Ben Coman]

Just curious what the magic numbers here relate to...
and can they be factored out to a meaningful method name?

Context>>gtInspectorVariableValuePairs
"This is a helper method that returns a collection of
variable_name -> value
for the current object.
Subclasses can override it to specialize what appears in the variables
presentation"
| bindings |
bindings := OrderedCollection new.
1 to: (self basicSize min: 21) do: [ :index |
bindings add: (index "asString""asTwoCharacterString" -> (self basicAt:
index)) ].
((self basicSize - 20) max: 22) to: (self basicSize) do: [ :index | "self
haltIf: [ index = 99 ]."
bindings add: (index "asString" -> (self basicAt: index)) ].
bindings
addAll: ((self class allSlots
collect: [ :slot | slot name -> (slot read: self) ]) sort
asOrderedCollection).
^ bindings


cheers -ben

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

[Ben Coman]

On Fri, Feb 3, 2017 at 10:13 AM, Ben Coman  wrote:

> Just curious what the magic numbers here relate to...
> and can they be factored out to a meaningful method name?
>
> Context>>gtInspectorVariableValuePairs
>

Whoops, this is...
Object>>gtInspectorVariableValuePairs


> "This is a helper method that returns a collection of
> variable_name -> value
> for the current object.
> Subclasses can override it to specialize what appears in the variables
> presentation"
> | bindings |
> bindings := OrderedCollection new.
> 1 to: (self basicSize min: 21) do: [ :index |
> bindings add: (index "asString""asTwoCharacterString" -> (self basicAt:
> index)) ].
> ((self basicSize - 20) max: 22) to: (self basicSize) do: [ :index | "self
> haltIf: [ index = 99 ]."
> bindings add: (index "asString" -> (self basicAt: index)) ].
> bindings
> addAll: ((self class allSlots
> collect: [ :slot | slot name -> (slot read: self) ]) sort
> asOrderedCollection).
> ^ bindings
>
>
> cheers -ben
>

Re: [Pharo-dev] GTDebugger variables table

[Ben Coman]

On Fri, Feb 3, 2017 at 12:28 AM, Denis Kudriashov  wrote:
>
> 2017-02-02 17:16 GMT+01:00 John Brant :
>>
>> I think my preference would be to have several tabs for the variables. In
>> addition to the one tab that we have now that shows all variables, I can
>> think of tabs for locals, inst vars, interesting variables, watched
>> variables/expressions, and stack variables. Locals would show just the
>> method/block arguments and any temps defined in the method.
>> Inst vars would
>> show the object's inst vars (and maybe class vars, however these would only
>> appear after the inst vars).
>>
>> Interesting variables would show locals and inst vars used by the method.
>> The locals would be limited to the ones that are still active at the current
>> location in the method. For example, if you are in a block, it would only
>> show variables used in the block.

>> Also, if you are before(/after) the first(/final) use of the variable,
>> it wouldn't show in the interesting list.

I'm not sure I'd like variables slipping in and out and rearranging
the middle of the list I'm looking at.  Perhaps scope could be
indicated another way like greying out variables.  It would be okay
for block variables to be added at the bottom.

>> Interesting variables should also do some analysis to see what accessor
>> methods are used and show their corresponding variables.

This is a nice idea.  It need not only be for interesting variables.
Ideally it would be a tab in the next pane to the right of the [Meta]
tab, but I guess its difficult since that pane is concerned with the
object, and linking back to the variable holding could be difficult.

>>
>> Watched variables/expressions would be user controlled. The user could
>> add/remove variables or expressions. These variables/expressions would
>> remain across different methods. If a variable didn't exist in the other
>> method, "Invalid" could be displayed.

I really miss this from my TurboPascal days.
The difficulty of course is avoiding side effects.

>>
>> Finally, stack variables would display the whole stack and not just the
>> top item. I like the ability to see the stack top, but it really doesn't
>> work if you want to see the first argument of a two argument message send.
>> For example, if you debug "Array with: OrderedCollection new with: Set new",
>> stepping over the "OrderedCollection new" immediately pushes the "Set" class
>> on the stack so you can't see the "OrderedCollection new" object.

Perhaps the stack could be another tab next to [Variables] ?
Or maybe it [Stack] would be better as a tab of thisContext's next pane.

>>
>>
>> BTW, the current variable list sometimes shows 'error obtaining field
>> value' for temporaries when stepping through a method. I'm not sure why it
>> occurs, but it should always be able to display the temp variables.
>
>
> I want everything you suggest :)

So we should try in Pharo 7.
cheers -ben

Re: [Pharo-dev] GTDebugger variables table

[Ben Coman]

On Fri, Feb 3, 2017 at 10:21 AM, Ben Coman  wrote:

> On Fri, Feb 3, 2017 at 12:28 AM, Denis Kudriashov 
> wrote:
> >
> > 2017-02-02 17:16 GMT+01:00 John Brant :
> >>
> >> I think my preference would be to have several tabs for the variables.
> In
> >> addition to the one tab that we have now that shows all variables, I can
> >> think of tabs for locals, inst vars, interesting variables, watched
> >> variables/expressions, and stack variables. Locals would show just the
> >> method/block arguments and any temps defined in the method.
> >> Inst vars would
> >> show the object's inst vars (and maybe class vars, however these would
> only
> >> appear after the inst vars).
> >>
> >> Interesting variables would show locals and inst vars used by the
> method.
> >> The locals would be limited to the ones that are still active at the
> current
> >> location in the method. For example, if you are in a block, it would
> only
> >> show variables used in the block.
>
> >> Also, if you are before(/after) the first(/final) use of the variable,
> >> it wouldn't show in the interesting list.
>
> I'm not sure I'd like variables slipping in and out and rearranging
> the middle of the list I'm looking at.  Perhaps scope could be
> indicated another way like greying out variables.  It would be okay
> for block variables to be added at the bottom.
>
> >> Interesting variables should also do some analysis to see what accessor
> >> methods are used and show their corresponding variables.
>
> This is a nice idea.  It need not only be for interesting variables.
> Ideally it would be a tab in the next pane to the right of the [Meta]
> tab, but I guess its difficult since that pane is concerned with the
> object, and linking back to the variable holding could be difficult.
>
> >>
> >> Watched variables/expressions would be user controlled. The user could
> >> add/remove variables or expressions. These variables/expressions would
> >> remain across different methods. If a variable didn't exist in the other
> >> method, "Invalid" could be displayed.
>
> I really miss this from my TurboPascal days.
> The difficulty of course is avoiding side effects.
>
> >>
> >> Finally, stack variables would display the whole stack and not just the
> >> top item. I like the ability to see the stack top, but it really doesn't
> >> work if you want to see the first argument of a two argument message
> send.
> >> For example, if you debug "Array with: OrderedCollection new with: Set
> new",
> >> stepping over the "OrderedCollection new" immediately pushes the "Set"
> class
> >> on the stack so you can't see the "OrderedCollection new" object.
>
> Perhaps the stack could be another tab next to [Variables] ?
> Or maybe it [Stack] would be better as a tab of thisContext's next pane.
>
>
Actually you can try...

Context>>stackValueMap
| stackValues stackDepth|
stackValues := OrderedCollection new.
stackDepth := self basicSize min: 21.
(stackDepth to: 1 by: -1) do: [ :index |
|key|
key := (index = stackDepth) ifTrue: ['Top'] ifFalse: [(stackDepth - index +
1) asString].
stackValues add: (key -> (self basicAt: index))
].
^stackValues

Context>>gtInspectorStackValuesIn: composite

| stackValues |
stackValues := self stackValues.
^ (composite table)
title: 'Stack';
display: [ self stackValueMap ];
column: 'Depth' evaluated: [ :assoc | assoc key ] width: 50;
column: 'Item' evaluated: [ :assoc | GTObjectPrinter new
asTruncatedTextFrom: assoc value ]


I'm not sure whether the #stackValueMap is an appropriate name. Perhaps it
should be #methodStackValueMap or something else?  Similar for the tab
name.

And I don't know what the magic number 21 is, as I queried here...
http://forum.world.st/magic-numbers-in-gtInspectorVariableValuePairs-tp4932831.html

cheers -ben