Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0
--- Begin Message --- 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: --- End Message ---
Re: [Pharo-users] [ANN] P3 version 1.1
--- Begin Message ---
Very cool. Thanks!
Doru
> On Dec 31, 2018, at 12:33 PM, Sven Van Caekenberghe 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."
--- End Message ---
Re: [Pharo-users] [Pharo-dev] New book: Pharo with Style
--- Begin Message --- Nice work. Doru > On Dec 30, 2018, at 10:13 PM, Stephane Ducasse > 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. > -- www.feenk.com "To utilize feedback, you first have to acquire it." --- End Message ---
Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0
--- Begin Message --- 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 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." --- End Message ---
Re: [Pharo-users] [ANN] P3 version 1.1
--- Begin Message --- > On 1 Jan 2019, at 02:12, Ben Coman wrote: > > > > On Mon, 31 Dec 2018 at 19:34, Sven Van Caekenberghe 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 --- End Message ---
Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0
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.
Re: [Pharo-users] (no subject)
--- Begin Message --- 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. --- End Message ---
Re: [Pharo-users] [Pharo-dev] New book: Pharo with Style
--- Begin Message --- That is a useful contribution, thank you (again) for your efforts ! > On 30 Dec 2018, at 22:13, Stephane Ducasse 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. > --- End Message ---
Re: [Pharo-users] [Pharo-dev] New book: Pharo with Style
--- Begin Message --- I’ve always felt the XP book nailed it - don’t use comments as a crutch to avoid fixing confusing code and don’t do work twice by simply writing a comment that says the same as the code. (You can of course try to write the comment and auto-generate the code, but we’ve tried that before). Smalltalk is an expressive language that should read like comments naturally - both with the name of a method, the variables and the statements in it. This leaves comments as a good place to tell a story about the wider context and where to look to get started or learn more. I think this is possibly where Documentor is going to help you navigate along the real code. Of course if after all of this you can’t figure out how to fix the code - then a comment is a good last resort. Tim Sent from my iPhone > On 1 Jan 2019, at 12:43, Alistair Grant wrote: > > Hi Richard, > >> On Tue, 1 Jan 2019 at 07:26, Richard O'Keefe wrote: >> >> ... >> >> To get an example, I did (String allSelectors atRandom), getting >> #copyWithoutAll:. That has only one definition, in Collection: >> copyWithoutAll: aCollection >> "Answer a copy of the receiver that does not contain any elements >> equal to those in aCollection." >> >> ^ self reject: [:each | aCollection includes: each] >> >> The comment simply paraphrases the rather simple code. > > I agree with pretty much everything you've written, but have a > slightly different view here. > > Including what the method does, even when the code is fairly simple > (OK, not getter / setter methods), is still useful. If the comment is > absent, I have to look at the code, figure out what it does, and then > either figure out if that's what it is supposed to do, or just assume > that I'm correct. Having to figure out whether I've interpreted the > code correctly just increases the cognitive load. If the comment > includes what it is supposed to do, I have a context in which to read > and evaluate the code, and it becomes much less effort. > > Cheers, > Alistair > --- End Message ---
Re: [Pharo-users] [Pharo-dev] New book: Pharo with Style
--- Begin Message --- Hi Richard, On Tue, 1 Jan 2019 at 07:26, Richard O'Keefe wrote: > > ... > > To get an example, I did (String allSelectors atRandom), getting > #copyWithoutAll:. That has only one definition, in Collection: >copyWithoutAll: aCollection > "Answer a copy of the receiver that does not contain any elements > equal to those in aCollection." > > ^ self reject: [:each | aCollection includes: each] > > The comment simply paraphrases the rather simple code. I agree with pretty much everything you've written, but have a slightly different view here. Including what the method does, even when the code is fairly simple (OK, not getter / setter methods), is still useful. If the comment is absent, I have to look at the code, figure out what it does, and then either figure out if that's what it is supposed to do, or just assume that I'm correct. Having to figure out whether I've interpreted the code correctly just increases the cognitive load. If the comment includes what it is supposed to do, I have a context in which to read and evaluate the code, and it becomes much less effort. Cheers, Alistair --- End Message ---
Re: [Pharo-users] how to use indexes to copy a substring out of a string
--- Begin Message ---
Let us approach this as simply as we can.
(1) There are two numbers 1 <= i <= n-3, i+2 <= j <= n-1
such that (s at: i) = (s at: j) and (s at: i+1) = (s at: j+1)
Brute force will get us where we want to go:
String
hasTwoCharacterNonoverlappingRepeat
1 to: self size - 3 do: [:i |
i + 2 to: self size - 1 do: [:j |
((self at: i ) = (self at: j ) and:
[(self at: i+1) = (self at: j+1)])
ifTrue: [^true]]].
^false
This is pretty much how you would do it in C or Java.
This takes O(n**2) time where n is the size of the string.
If you want to be *really* clever, you can do something with
suffix arrays, but if you just want to be a little bit clever,
you can sort the two-character substrings and their positions
by just sorting the positions.
Make an array a of the integers 1..n-1.
Sort it by viewing each i in the array as the triple
(s[i],s[i+1],i). You don't *make* the triples, just do the
comparisons as if they existed.
Now a linear scan of the array will find a match if there is one.
The whole process is O(n.lg n). It's only worth doing when n is
large.
(2) Finding xyx. You did not say whether the middle letter can be the same
as the outer ones or must be different. I'm going to suppose that it
does not matter.
hasXYX
3 to: self size do: [:i |
(self at: i-2) = (self at: i) ifTrue: [^true]].
^false
Again, this is just what you would do in Java or C:
public static boolean hasXYX(String s) {
final int n = s.length();
for (int i = 2; i < n; i++)
if (s.charAt(i-2) == s.charAt(i)) return true;
}
return false;
}
For what it's worth, in my system this scans a Scrabble dictionary
with 146522 words (1,220,068 bytes), finding 2779 "nice" words,
in 0.18 seconds, so there's not a lot of point in improving it.
In both cases, DON'T copy. DON'T make substrings.
Just state the problem simply and convert it to obvious code.
Simple boring code is GOOD.
On Sun, 30 Dec 2018 at 05:29, Roelof Wobben wrote:
> Hello,
>
> Still working on AdventOfCode
>
> Im struggeling to see how this can be solved.
>
> Now, a nice string is one with all of the following properties:
>
>- It contains a pair of any two letters that appears at least twice in
>the string without overlapping, like xyxy (xy) or aabcdefgaa (aa), but
>not like aaa (aa, but it overlaps).
>- It contains at least one letter which repeats with exactly one
>letter between them, like xyx, abcdefeghi (efe), or even aaa.
>
> my game plan was this
>
> 1) group the characters and filter everything out which has a count not
> equal to two
>
> 2) find the indexes of the characters and with the indexes use a copy
> method so I have a substring out of it
>
> 3) do the same with the substring so again 1 and 2
>
> but how can I make 2 work.
>
> Roelof
>
>
>
--- End Message ---
