- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GTDebugger variables table

by 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

Feb. 2, 2017

Re: [Pharo-dev] Zinc / REST misunderstanding

by Sven Van Caekenberghe

> On 2 Feb 2017, at 16:51, Nicolas Anquetil <nicolas.anquetil(a)inria.fr> 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:<mypasswd> http://<theserver>/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 <theserver>... > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to <theserver> (<theserver>) port 80 (#0) > * Server auth using Basic with user 'anquetil' > > PUT /redmine/issues/430.json HTTP/1.1 > > Host: <theserver> > > 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 110 0 0 100 110 0 546 --:--:-- --:--:-- --:--:-- 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 110 0 0 100 110 0 105 0:00:01 0:00:01 --:--:-- 105 > * Connection #0 to host <theserver> 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://<theserver>/redmine/' asZnUrl ) > contentType: (ZnMimeType main: 'application' sub: 'json')) ; > contentLength: cont size. > > ZnClient new > beOneShot ; > entity: ent ; > username: 'anquetil' password: '<mypasswd>' ; > put: 'http://<theserver>/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://<theserver>/redmine/issues/430.json' ; entity: ent ; username: 'anquetil' password: '<mypasswd>' ; 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: > > <cicgeiiljjcidaam.png> > > The response of ZnClient is "200 OK", with again the same headers as reported by curl > > <mjlnpnjhhegjmhnl.png> > > 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 >

Feb. 2, 2017

Zinc / REST misunderstanding

by 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:<mypasswd> http://<theserver>/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 <theserver>... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to <theserver> (<theserver>) port 80 (#0) * Server auth using Basic with user 'anquetil' > PUT /redmine/issues/430.json HTTP/1.1 > Host: <theserver> > 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 110 0 0 100 110 0 546 --:--:-- --:--:-- --:--:-- 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 110 0 0 100 110 0 105 0:00:01 0:00:01 --:--:-- 105 * Connection #0 to host <theserver> 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://<theserver>/redmine/' asZnUrl ) contentType: (ZnMimeType main: 'application' sub: 'json')) ; contentLength: cont size. ZnClient new beOneShot ; entity: ent ; username: 'anquetil' password: '<mypasswd>' ; put: 'http://<theserver>/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

Feb. 2, 2017

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

by 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 <astares(a)gmx.de> 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/

Feb. 2, 2017

Re: [Pharo-dev] GTDebugger variables table

by 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 <nicolas.anquetil(a)inria.fr> 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.

Feb. 2, 2017

Re: [Pharo-dev] GTDebugger variables table

by 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

Feb. 2, 2017

GTDebugger variables table

by 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?

Feb. 2, 2017

Re: [Pharo-dev] [Vm-dev] pb with primitive #primitiveScreenDepth on Linux ?

by Christophe Demarey

Hello Bert, > Le 31 janv. 2017 Ã 18:18, Bert Freudenberg <bert(a)freudenbergs.de> a Ã©crit : > > On Tue, Jan 31, 2017 at 10:44 AM, Christophe Demarey <christophe.demarey(a)inria.fr <mailto:christophe.demarey@inria.fr>> wrote: > > Hello, > > With Pavel, we discovered a strange behavior of the primitive #primitiveScreenDepth on Linux. It returns a value of 24 bits per pixel (True colors) that looks valid but not supported (at least by Pharo). > > DisplayScreen actualScreenDepth "(calling the primitive screenDepth)" > => 32 on OS X [OK] > => 24 on Linux [KO] > > Also, it is not consistent with the primitive 91 > > DisplayScreen new supportsDisplayDepth: DisplayScreen actualScreenDepth > => true on OS X > => false on Linux > > There are some safeguard image-side but it would be great if someone could check that vm side. > > That seems wrong indeed, since BitBlt can only handle power-of-two depths currently. It should answer 32 or -32 in this case. > > Actually ... is there a difference in pixel layout for 32 bit MSB vs LSB forms? A quick test in SqueakJS suggests there isnât. I do not get what you mean by 32 bits MSB vs LSB form. Could you give an example of what to test? If you mean a difference between depth 32 or -32, I do not see any difference. Christophe

Feb. 2, 2017

Re: [Pharo-dev] [Ann] Calypso update: method browser and better UI

by Stephan Eggermont

On 31/01/17 21:10, Denis Kudriashov wrote: > I always said that UI needs much more work. But my question was to your > "don't mix styles". > Do you think it looks worse than before? I like the toolbar in the middle, and the separators. > I am not designer and would be very appreciate if somebody paint how it > should be. I'll take a look at it, but am a bit slow at the moment. Attached is current painting state of a morph that might be useful. Stephan

Feb. 2, 2017

Re: [Pharo-dev] PharoLauncher create image / default image name

by Cyril Ferlicot D.

Le 01/02/2017 Ã 20:18, Nicolai Hess a Ã©crit : > I started to use a more recent version of pharo launcher, and somehow it > changed how it creates the default image name when creating a new image. > For example, select an entry from "Pharo 6.0 (beta)" template, the old > behavior sets the default name to > Pharo 6.0 (beta) - 60353 > but now, the template name is omitted, it only sets > 60535 > > was this change on purpose ? I can not find an issue about this on > https://github.com/pharo-project/pharo-launcher/issues > > (I actually don't care much about which format to use, it is just that > all my images I used from the prior version, and the new one now appear > on different positions in the images list) > > nicolai Hi, This change was made by Christophe I think and was in purpose. Template name before: Name of the "location" (ex: Common Tools, Pharo Contribution Jenkins, Pharo 6.0â¦) - Name of the build Now: Name of the build -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Feb. 1, 2017