January 2019 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

by Konrad Hinsen

Hi Doru and Offray, Tudor Girba via Pharo-users <pharo-users(a)lists.pharo.org> writes: > A separate editor is needed when the markup has little resemblance > with the output, which is the case for HTML. In this case, > bidirectional editing, as shown in Sketch-n-Sketch, is indeed a very > nice thing. Or when the output reflects only a part of the input document. I suspect Offray has the same kind of application in mind as myself, knowing a bit of his work, and it is indeed a bit different from what you are designing GT for. What we do (mainly) is documenting computations, not software. A computation consists of code, input data, and selected results. This inevitably requires some metadata that needs to be editable but should not necessarily appear in the output. The most basic technology for documenting computations is the notebook (Mathematica, Jupyter, ...) where the metadata is just the cell structure (which does show in the output). More sophisticated systems (Emacs OrgMode for example) allow more fine-tuning, making for much nicer output, but also requiring quite a bit more metadata. > However, in the case of Documenter and the Pillar markup the output is > closely related to the sources part. In this case, having the two >From what I know about Pillar, I agree. The way this is handled in Documenter is indeed very appropriate for very simple markup like that. And simple markup is highly desirable whenever sufficient. > worlds be supported seamlessly in the same experience is a huge > advantage, especially for non-technical people. The interface from > Documenter is not trivially possible (I for now never saw one like > that, and I looked specifically for it) because of the prerequisites The closest I have seen is MarkText: https://marktext.github.io/website/ Its "focus mode" works much like Documenter in principle, but feels less fluent somehow. Offray Vladimir Luna CÃ¡rdenas via Pharo-users <pharo-users(a)lists.pharo.org> writes: > but is not their only concern. ATM seems that new GT is pretty tied to > Pillar and software documentation (which is fine, but not the path I'm > primarily interested). Me neither, but I still find a lot of interesting ideas in GT and I suspect that a tool closer to my interests could be built with reasonable effort from the bricks that GT provides. My holy grail is a document that describes both software and computations, combining the features of notebooks and literate programming into a hypertext-like system in which I can start at the surface (the computation) and "zoom in" to any part of the software, getting documentation and not just source code. Cheers, Konrad.

Jan. 2, 2019

Is it possible to follow an object through a computation?

by PAUL DEBRUICKER

Hi - Is there a way to haltOnChange or some such for an object? I have an instance that gets into a state I don't understand and would like to watch it or several of its inst vars for when they change. I could set a lot of #haltIf: statements and step through but hope someone has a better strategy thanks & happy new year. Paul

Jan. 2, 2019

Re: [Pharo-users] [ANN] P3 version 1.1

by Guillermo Polito

Thanks Sven :) On Tue, Jan 1, 2019 at 11:54 PM Tudor Girba via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Very cool. Thanks! > > Doru > > > > On Dec 31, 2018, at 12:33 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > Hi, > > > > I created a new release of P3, the modern, lean and mean PostgreSQL > client for Pharo. > > > > https://github.com/svenvc/P3 > > > > Version 1.1 contains the following changes: > > > > - added support for Postgres Extended Query protocol > (P3PreparedStatement) (thx Jan @jvdsandt) > > - added support for reading array type values (currently INTEGER[] > FLOAT[] BOOLEAN[] TEXT[] VARCHAR[]) > > - added P3-Tests package and moved all tests there > > - more comments > > - more unit tests > > > > https://github.com/svenvc/P3/releases/tag/v1.1 > > > > > > Especially Jan's contribution adds a lot of functionality: the ability > to work with prepared statements. > > > > Here is an example doing a batch insert of 100 records (which is more > efficient). > > > > | client statement | > > > > client := P3Client url: 'psql://sven@localhost'. > > > > client execute: 'DROP TABLE IF EXISTS table1'. > > client execute: 'CREATE TABLE table1 (id SERIAL PRIMARY KEY, created_at > TIMESTAMP DEFAULT NOW(), name TEXT)'. > > > > statement := client prepare: 'INSERT INTO table1 (name) VALUES ($1)'. > > statement executeBatch: ((1 to: 100) collect: [ :index | Array with: > ('Text #', index printString) ]). > > > > client query: 'SELECT * FROM table1'. > > client execute: 'DROP TABLE table1'. > > > > statement close. > > client close. > > > > > > Season's Greetings to you all. > > > > Sven > > > > > > -- > > Sven Van Caekenberghe > > Proudly supporting Pharo > > http://pharo.org > > http://association.pharo.org > > http://consortium.pharo.org > > > > > > > > > > -- > www.feenk.com > > "To utilize feedback, you first have to acquire it." > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Jan. 2, 2019

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

by Offray Vladimir Luna CÃ¡rdenas

Hi, Thanks Konrad for the Sketch-n-Sketch link.Â I think that you hit the point about having multiple editors and views for the same object. I think that for interactive documentation that goes beyond software, that is needed, specially when you are targeting single source input and multi device/format output (like here [1]). Several Markdown variants are targeting such scenario, that includes interactive documentation, but is not their only concern. ATM seems that new GT is pretty tied to Pillar and software documentation (which is fine, but not the path I'm primarily interested). [1] https://mutabit.com/repos.fossil/mapeda/ I will see what future Pharo 7 based toolkits bring on that front. Cheers, Offray On 1/1/19 16:50, Tudor Girba via Pharo-users wrote:

Jan. 1, 2019

Re: [Pharo-users] [ANN] P3 version 1.1

by Tudor Girba

Very cool. Thanks! Doru > On Dec 31, 2018, at 12:33 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > I created a new release of P3, the modern, lean and mean PostgreSQL client for Pharo. > > https://github.com/svenvc/P3 > > Version 1.1 contains the following changes: > > - added support for Postgres Extended Query protocol (P3PreparedStatement) (thx Jan @jvdsandt) > - added support for reading array type values (currently INTEGER[] FLOAT[] BOOLEAN[] TEXT[] VARCHAR[]) > - added P3-Tests package and moved all tests there > - more comments > - more unit tests > > https://github.com/svenvc/P3/releases/tag/v1.1 > > > Especially Jan's contribution adds a lot of functionality: the ability to work with prepared statements. > > Here is an example doing a batch insert of 100 records (which is more efficient). > > | client statement | > > client := P3Client url: 'psql://sven@localhost'. > > client execute: 'DROP TABLE IF EXISTS table1'. > client execute: 'CREATE TABLE table1 (id SERIAL PRIMARY KEY, created_at TIMESTAMP DEFAULT NOW(), name TEXT)'. > > statement := client prepare: 'INSERT INTO table1 (name) VALUES ($1)'. > statement executeBatch: ((1 to: 100) collect: [ :index | Array with: ('Text #', index printString) ]). > > client query: 'SELECT * FROM table1'. > client execute: 'DROP TABLE table1'. > > statement close. > client close. > > > Season's Greetings to you all. > > Sven > > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > -- www.feenk.com "To utilize feedback, you first have to acquire it."

Jan. 1, 2019

Re: [Pharo-dev] New book: Pharo with Style

by Tudor Girba

Nice work. Doru > On Dec 30, 2018, at 10:13 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hello Fellow Pharoers > > I'm happy to announce a new little book to improve the culture around Pharo. > I will revise it in the future so you can feel free to send feedback > and pull requests > to https://github.com/SquareBracketAssociates/Booklet-PharoWithStyle > > Stef > > "The best way to predict the future is to invent" so I do it. > <withstylebook.pdf> -- www.feenk.com "To utilize feedback, you first have to acquire it."

Jan. 1, 2019

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

by Tudor Girba

Hi, A separate editor is needed when the markup has little resemblance with the output, which is the case for HTML. In this case, bidirectional editing, as shown in Sketch-n-Sketch, is indeed a very nice thing. However, in the case of Documenter and the Pillar markup the output is closely related to the sources part. In this case, having the two worlds be supported seamlessly in the same experience is a huge advantage, especially for non-technical people. The interface from Documenter is not trivially possible (I for now never saw one like that, and I looked specifically for it) because of the prerequisites it needs from underlying graphical framework, but I do think itâs a significant step forward in the notebooks space. Cheers, Doru > On Jan 1, 2019, at 8:01 PM, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > > Hi Offray and Doru, > > allow me to chirp in on a topic that I have been thinking about for a > while: > >>> Interesting observation. The linked tools as all other notebook >>> technologies I saw rely on two distinct modes for edit and view that >>> reside in two distinct widgets (editor and viewer). They do that >>> because they simply cannot have it in one. Because of the design of >>> Bloc we are not constrained to that. Instead, we build a seamless >>> interface that is both optimized for viewing, and for editing with >>> live preview that does not rely on an explicit render button. This >>> approach enables direct manipulation without friction, and we think >>> this is a significant advancement in this space. > >> I don't think is only because other editors can't do it, but because >> some (most) times you don't want "to conflate two tasks that are >> /conceptually/ distinct and that, to ensure that people's time is used >> most effectively and that the final communication is most effective, >> ought also to be kept /practically/ distinct"[1] which are Composition >> and typesetting. > > Two remarks. > > First, this is a special case of the more general issue of having > multiple views and even multiple editors for a single object. No matter > what you believe to be the best approach to editing text with markup, in > many other situations it is clearly desirable to have multiple > views/editors side by side, and I have regretted more than once that > this doesn't seem to be possible in Pharo's inspector. > > For multiple editors the need to have them side by side is probably more > obvious than for mere views, so it may be useful to look at practical > examples and see how one would realize them in Pharo and/or in GT. One > of my favorite applications is graphics that are generated by program > code but can also be edited graphically, as implemented in > Sketch-n-Sketch (https://ravichugh.github.io/sketch-n-sketch/) > You definitely want the two panes, code and graphics, side by side. > > Second, the example of editing text with markup also illustrates that it > matters if views are complete (i.e. show all the available data) or > partial, and if they are invertible, i.e. if a change in an editable > view can be translated unambiguously into a change in the underlying > data. Markup with comments, as mentioned by Offray, is a case in which > the rendered view is partial but nevertheless invertible, so it makes > sense to have two types of editors, one for the raw markup text and one > for the rendered version. Some people may want both side by side, > whereas others may prefer a single one with the possibility to switch, > depending on how important the non-rendered information is. > > Scientific data visualization provides plenty of interesting examples by > the way, often with the additional challenge of significant > computational cost in rendering. > > Konrad. > -- www.feenk.com "Innovation comes in the least expected form. That is, if it is expected, it already happened."

Jan. 1, 2019

Re: [Pharo-users] [ANN] P3 version 1.1

by Sven Van Caekenberghe

> On 1 Jan 2019, at 02:12, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Mon, 31 Dec 2018 at 19:34, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > I created a new release of P3, the modern, lean and mean PostgreSQL client for Pharo. > > https://github.com/svenvc/P3 > > Version 1.1 contains the following changes: > > - added support for Postgres Extended Query protocol (P3PreparedStatement) (thx Jan @jvdsandt) > - added support for reading array type values (currently INTEGER[] FLOAT[] BOOLEAN[] TEXT[] VARCHAR[]) > - added P3-Tests package and moved all tests there > - more comments > - more unit tests > > https://github.com/svenvc/P3/releases/tag/v1.1 > > > Especially Jan's contribution adds a lot of functionality: the ability to work with prepared statements. > > This is great to hear. Could you advise what functionality remains missing, and what priority you'd consider each is? > > cheers -ben >From its initial release, P3 covered enough to support GLORP, a complex object relational mapper with hundreds of unit tests. After that several new features and support for more primitive types was added. So overall, we are in a good place, and P3 is fully functional and useable for real applications. At the protocol level, I think the most important missing part is probably COPY support. Regarding primitive types, PostgreSQL is a bit special in the fact that it has a large, even infinite amount of primitive types, that are extensible by both plugins and users. P3 currently supports the following 26 primitive types: #(#_bool #_float8 #_int4 #_text #_varchar #bool #bpchar #bytea #date #float4 #float8 #int2 #int4 #int8 #json #jsonb #name #numeric #oid #text #time #timestamp #timestamptz #uuid #varchar #void) These are internal PG specific type names, some types have better know aliases. On my machine, pg_type contains more than 600 types though ! Do we need them all ? No. But there will be use cases where people ask for more types, most should be pretty easy to add. Like for all open source code, the best scenario is to have lots of users, so that the code can be improved where needed to become truly battle tested. Sven

Jan. 1, 2019

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

by Konrad Hinsen

Hi Offray and Doru, allow me to chirp in on a topic that I have been thinking about for a while: >> Interesting observation. The linked tools as all other notebook >> technologies I saw rely on two distinct modes for edit and view that >> reside in two distinct widgets (editor and viewer). They do that >> because they simply cannot have it in one. Because of the design of >> Bloc we are not constrained to that. Instead, we build a seamless >> interface that is both optimized for viewing, and for editing with >> live preview that does not rely on an explicit render button. This >> approach enables direct manipulation without friction, and we think >> this is a significant advancement in this space. > I don't think is only because other editors can't do it, but because > some (most) times you don't want "to conflate two tasks that are > /conceptually/ distinct and that, to ensure that people's time is used > most effectively and that the final communication is most effective, > ought also to be kept /practically/ distinct"[1] which are Composition > and typesetting. Two remarks. First, this is a special case of the more general issue of having multiple views and even multiple editors for a single object. No matter what you believe to be the best approach to editing text with markup, in many other situations it is clearly desirable to have multiple views/editors side by side, and I have regretted more than once that this doesn't seem to be possible in Pharo's inspector. For multiple editors the need to have them side by side is probably more obvious than for mere views, so it may be useful to look at practical examples and see how one would realize them in Pharo and/or in GT. One of my favorite applications is graphics that are generated by program code but can also be edited graphically, as implemented in Sketch-n-Sketch (https://ravichugh.github.io/sketch-n-sketch/) You definitely want the two panes, code and graphics, side by side. Second, the example of editing text with markup also illustrates that it matters if views are complete (i.e. show all the available data) or partial, and if they are invertible, i.e. if a change in an editable view can be translated unambiguously into a change in the underlying data. Markup with comments, as mentioned by Offray, is a case in which the rendered view is partial but nevertheless invertible, so it makes sense to have two types of editors, one for the raw markup text and one for the rendered version. Some people may want both side by side, whereas others may prefer a single one with the possibility to switch, depending on how important the non-rendered information is. Scientific data visualization provides plenty of interesting examples by the way, often with the additional challenge of significant computational cost in rendering. Konrad.

Jan. 1, 2019

Re: [Pharo-users] (no subject)

by Konrad Hinsen

Offray, > It's really nice to have you hear. I remember some of our Twitter Thanks for the welcome! > I restarted with Pharo in 2014, after a short revealing experience with > Squeak, EToys and Bots Inc in 2006-2007 and now I'm enjoying the Joyride[1] > > [1] https://twitter.com/offrayLC/status/493979407011561473 Nice :-) I guess the tough part is figuring out where you are on that curve! Konrad.

Jan. 1, 2019