[Pharo-users] Monticello
Hi, I wonder if anyone is familiar enough with Monticello to know how to code up a quick commit history report showing all commits and comments for a given date range? -- Ramón León http://onsmalltalk.com
Re: [Pharo-users] Do we have a simple markdown parser?
On 2020-03-26 3:24 p.m., Eric Gade wrote: Hi Ramón, I have a couple of questions. If you are using OSProcess in Pharo 8 I'm not, I don't try and keep up with the latest stuff, too much churn. But I'd imagine the latest must still be able to pipe out to a command even if the API changed a bit. but the new ZnStreams in P7/P8 DNU on #isOssPipe and StandardFileStream (for which OSSubprocess was designed, evidently) is being deprecated. And this is why it's not worth riding the bleeding edge. Go back and find a stable older version you like and stick with it. Let others get all cut up playing with unstable new stuff. -- Ramón León
Re: [Pharo-users] Do we have a simple markdown parser?
On 2020-03-24 10:51 a.m., Tim Mackinnon wrote: Hi guys - do we have a simple markdown parser that is reasonably up to date? What's wrong with the real markdown itself? I've used the original Markdown.pl implementation for years same as I would any other shell script, via OSProcess markdown: someContent ^UnixProcess pipeString: someContent throughCommand: (FileDirectory default fullPathFor: 'Markdown.pl') -- Ramón León
Re: [Pharo-users] [ANN] Phoedown - Markdown to HTML
On 2020-01-02 10:56 a.m., Sean P. DeNigris wrote: While I dream of a world where everything is in-image as pure Smalltalk, given the reality of limited manpower, I think of outside library use as a way to "cheat" and get a lot more from that limited engineering resource. Agree, I've used the original Markdown.pl implementation for years same as I would any other shell script, via OSProcess markdown: someContent ^UnixProcess pipeString: someContent throughCommand: (FileDirectory default fullPathFor: 'Markdown.pl') Never saw a need to rewrite what already works in its original form. -- Ramón León VP of Technology Alliance Reservations Network
Re: [Pharo-users] [ANN] Phoedown - Markdown to HTML
On 2020-01-02 10:56 a.m., Sean P. DeNigris wrote: While I dream of a world where everything is in-image as pure Smalltalk, given the reality of limited manpower, I think of outside library use as a way to "cheat" and get a lot more from that limited engineering resource. Agree, I've used the original Markdown.pl implementation for years same as I would any other shell script, via OSProcess markdown: someContent ^UnixProcess pipeString: someContent throughCommand: (FileDirectory default fullPathFor: 'Markdown.pl') Never saw a need to rewrite what already works in its original form. -- Ramón León
Re: [Pharo-users] Code of Conduct
On 2019-09-20 3:03 p.m., Steve Quezadas wrote: I think the "covenant" should be a single line: "keep the subject matter on pharo, anything else is off-topic". This list should be politically neutral. I agree. The leadership apparently does not, left wing social justice identity politics is now embedded into the community rules. Guess we'll see what happens when outsiders start trying to use it to cancel people as is happening just about everywhere these CoC's are introduced. -- Ramón León
Re: [Pharo-users] Code of Conduct
On 2019-09-20 12:33 p.m., Ben Coman wrote: A fair response Ben. A good compromise is sometimes said to be when opposing parties are> **equally** dissatisfied. The new version is much better, I believe I said that. James and Norbert made some final and excellent changes that mostly fixed what was wrong and removed the overreach and the lack of due process. That feels to me like an extreme interpretation. It's not, identity politics are left wing politics and putting them in the CoC is absolutely imposing them on the community. I guess we'll see how it goes. -- Ramón León
Re: [Pharo-users] Code of Conduct
On 2019-09-20 7:44 a.m., Steve Quezadas wrote: Or maybe you're too easily offended and the problem lies with you. It's fairly obvious now, the Pharo leadership is occupied by left wing progressives who are intent on bringing identity politics into the community. While the new CoC is vastly better in its current state, it still insists one the left wing political ideology of respecting people's chosen identities as if that has any bearing at all on anything. * One's identity is not relevant in a technical forum. * One's code is not better because of one's identity. * One's arguments are not more sound because of one's identity. * Ones point of view are not more important because of one's identity. Any calls to respect someone's identity are thinly veiled attempts to impose objectionable left wing political language onto the community. I don't care how anyone identifies, but I'm under no obligation to play along and it is not disrespectful to disagree with these political beliefs. The maintenance of ones identity and self image is theirs to worry about, I have no obligation to support the maintenance of someone else's ego. You can identify as a pink unicorn for all I care, but no I do not have to respect that or play along. Nor will I. I'm saying this here because the pull request to remove the word identity was rejected without explanation, discussion, or comment. Progressives seem intent on ruining everything. -- Ramón León
Re: [Pharo-users] Code of Conduct
On 2019-09-17 5:11 p.m., James Foster wrote: If there was, indeed, adoption of a “Covenant” it should have been done by the board whose role “is to make decisions if in the future the community can't decide on a course of action” (https://pharo.org/about). I suggest that we suspend discussion of the politics of speech codes until we confirm that there is one for Pharo. https://github.com/pharo-project/pharo/blob/Pharo8.0/CODE_OF_CONDUCT.md -- Ramón León
Re: [Pharo-users] Code of Conduct
On 2019-09-17 4:26 p.m., Richard O'Keefe wrote: I see the so-called "Covenant" that we are discussing as another example of this urge to micro-control other people. It has me nervously looking for the exit. I couldn't agree more. -- Ramón León
Re: [Pharo-users] Code of Conduct
On 2019-09-17 2:34 p.m., Offray Vladimir Luna Cárdenas wrote: as I say the important issue is to provide safe spaces via explicit or implicit rules I understand, I just disagree. These are of course my personal opinions, others may disagree. "Safe spaces" are bad things, not good things; the world is not a safe space, it is not the responsibility of others to provide one a feeling of safety in a an online community where people merely exchange words. Words are not dangerous, you are already safe. If you don't like what someone is saying, ignore them or mute them. Safe space a euphemism for censorship and exclusion, people who want safe spaces want to exclude other people who might express ideas or opinions that they disagree with. Safe spaces are anti-free speech zones. They are an attempt to prepare the world for the child rather than the child for the world; they are inherently narcissistic. Intellectual discourse is supposed to be challenging to your beliefs, you're supposed to confront ideas you might not like or agree with and people you might have a hard time getting along with. If you submit code to a technical forum you should expect criticism and debate. Technical discussions should resolve around the ideas being presented, not around the identities of those involved, and ideas should always be open to critique and debate. I don't care what one's sex or gender are or what color one's skin is or political beliefs are; those things have no place in a technical forum. I watch these groups to see discussions about technology like Pharo, Squeak, or Seaside. It's a rare thing to see anyone here being truly rude, there's no need for a code of conduct, it's a non solution to a non problem intended only to divide and punish for political ends. Maybe I'm just getting old, but the younger generation is far too coddled and expectant of the world to adjust to their feelings rather than learning how to deal with the world and others who have different ideas than they do. Safe spaces are bad ideas. -- Ramón León
Re: [Pharo-users] Code of Conduct
On 2019-09-17 6:28 a.m., Offray Vladimir Luna Cárdenas wrote: I'm pretty secure that Code of Conducts intent to provide secure spaces beyond just digital spaces and go also into physical and face to face ones. The code of conducts intent is to force identity politics into technical spaces in the name of social justice and to make someone feeling offended an actionable reason to go after the supposed offender; never mind that offense is taken rather than given. Nevermind that anyone can claim to be offended by just about anything. The goal is to get the project to agree to kick people out for violating the utterly vague and subjective rules. Here's some more quotes from the author of said code of conduct. "Some people are saying that the Contributor Covenant is a political document, and they’re right." "I can’t wait for the mass exodus from Linux now that it’s been infiltrated by SJWs. Hahahah" "Meritocracy is just thinly veiled misogyny and white supremacy propping up fragile cis het white men's egos" "Meritocracy is late stage patriarchy" "Why didn’t anyone punch the reporter giving the nazi air time?" He is a radical left transgender activist, his intentions are purely political, the CoC is merely a means to an end and is used by him to setup situations in which he can cancel people in this new cancel culture. He wants to replace meritocracy with identity politics. This is the CoC that ran Linus out of Linux, a massive loss to the OS community. This is not a horse you want to hitch your wagon to Pharo. -- Ramón León
Re: [Pharo-users] Richard Kenneth Eng is NOT Mr. Smalltalk
On 2019-04-09 1:17 p.m., horrido wrote:
BTW, I've also said many unkind things about Python. And C++. And Scala and
Swift. But I'm being criticized for what I've said about JavaScript?
Really???
There is certainly no hint of bias here.
Richard, you keep doing what you're doing; that guy doesn't know what
the fuck he's talking about.
> The quote I mentioned ("just object all
the way down") was one of the blog topics the managers, to whom I tried
to advertise Pharo, found ridiculous and laughed at it ("does it work
by magic then? What are the primitives and basic value types then?"
It's not your fault neither he nor his manager have any idea what
objects all the way down means and that he thinks JS and a whole bunch
of other languages have done this just shows he still has no idea what
objects all the way down means.
These easily offended people and their entitlement to think they can
tell you what you should or shouldn't say about a language you like can
be dealt with by telling them to go fuck themselves.
I've liked your articles, and JavaScript is a shitty language no matter
how many newbs pick it up; popularity doesn't mean quality.
--
Ramon Leon
Re: [Pharo-users] Lazy vs eager initialization
On 05/29/2018 08:49 AM, sergio ruiz wrote: If a model has a list of things.. such as a user that can/may have lots of pets, are there any real benefits to initializing the list of pets lazily? Yes, there's a huge benefit to lazy initialization; it's more resilient to class changes in the face of deserilization of old class shapes. If you add new instance vars to a class, and then deserialize older version those instance variables will be nil. With lazy init, this is not a problem. Without lazy init, this is a null ref exception. These old versions could be from a cache of data from the previous version of the code. It's no fun to have to lose all cache data just because you push out a new version of the code. In of the face of persistence, i.e. serialized versions of your objects, lazy init is the way to go. -- Ramon Leon
Re: [Pharo-users] #ast vs. #parseTree
On 05/05/2018 03:08 AM, Sean P. DeNigris wrote: and may buy us little at the cost of a good amount of extra typing. Auto-completion killed that argument long ago. Method names are for reading, not writing; the computer will do most of the writing for you. If you're optimizing key strokes when deciding a method name, you're doing it wrong. -- Ramon Leon
Re: [Pharo-users] #ast vs. #parseTree
On 05/04/2018 01:29 AM, Ben Coman wrote: a TMA situation? And my point made; I don't even know what that means. -- Ramon Leon
Re: [Pharo-users] #ast vs. #parseTree
On 05/03/2018 12:02 PM, Guillermo Polito wrote: I don't think so... any compiler book talks about ASTs using acronyms. Acronyms are good when acronyms are good. Boo, acronyms bad, virtually always. Jargon is awful when speaking and awful when Smalltalk'ing, use words, they're not in short supply. -- Ramon Leon
Re: [Pharo-users] Using SandstoneDB for persistance. Getting error.
On 07/11/2017 10:05 AM, sergio ruiz wrote: Oh! i forgot to mention.. this method belongs to Order.. so that part is working just fine.. Doesn't matter where the method is, your state machine clearly has blocks stored as instance variables and you're trying to save the state machine as part of the Order; SandstoneDb doesn't support saving blocks. I'd try what Dennis Suggested and store message sends rather than blocks for the guarded method, then it might save fine. Inspect the state machine, any use of blocks has to be removed/changed to message sends in order for it to be persistable by SandstoneDb. -- Ramon Leon http://onsmalltalk.com
Re: [Pharo-users] Hot to retrieve values from Nested Dictionaries
On 04/24/2017 11:16 AM, Esteban A. Maringolo wrote:> For these use cases it would be nice to have some sort of syntax sugar as with the cascade operator, but with a chaining operator instead. This doesn't even require syntactic sugar, just objects, and this is a more general problem even with a back to back chain of select/detect/reject style things. I solved this for myself years ago by introducing what I call a pipe (nod to unix) allowing me to chain calls in a pipeline without all the parens with each call acting on the result value of the last call. Trivially implemented using #doesNotUnderstand: and the cascade operator. ^ dict1 asPipe at: 'key1'; at: 'key2'; at: 'key3'. Anytime I have a bunch of back to back calls that would require a lot of parens, I just create a pipe... maxRoomsAvailable ^self findBlocks asPipe select: [ :e | e blockDate between: actualCheckInDate and: actualCheckInDate + (nights - 1) days ]; detectMin: [ :e | e quantityAvailable ]; quantityAvailable The simplest implementation is... Object>>asPipe ^ SPipe with: self Object subclass: #SPipe instanceVariableNames: 'value' classVariableNames: '' poolDictionaries: '' category: 'PharoExtensions' privateValue: anObject value := anObject yourself ^ value yourself doesNotUnderstand: aMessage ^ value := value perform: aMessage selector withArguments: aMessage arguments SPipe class>>with: anObject ^ (self new) privateValue: anObject; yourself -- Ramon Leon
Re: [Pharo-users] real world pharo web application set ups
On 12/14/2016 12:09 PM, Esteban A. Maringolo wrote: Can you extend on suspending the UI process? I never did that. I feed my images a start script on the command line pharo-vm-nox \ -vm-sound-null -vm-display-null \ /var/pharo/app.image \ /var/pharo/startScript startScript containing one line (among others) like so... Project uiProcess suspend. I'm on an older Pharo, but I presume the newer ones are the same or similar. No sense in wasting CPU on a UI in a headless image Won't the idle use add up? Sure eventually, but you don't run more than a 2 or so per core so that'll never be a problem. You shouldn't be running 5 images on a single core, let alone more. In my case I served up to 20 concurrent users (out of ~100 total) with only 5 images. Plus another two images for the REST API. In a dual core server. That's barely a server, most laptops these days have more cores. Rent a virtual server with a dozen or more cores, then you can run a few images per core without the idle mattering at all and run 2 dozen images in total per 12 core server. Scale by adding cores and ram allowing you to run more images per box; or scale by running more boxes, ultimately, you need to spread out the load across many many cores. -- Ramon Leon
Re: [Pharo-users] real world pharo web application set ups
On 12/14/2016 10:27 AM, Esteban A. Maringolo wrote: Memory is cheap, and the only limit now is CPU, the current Pharo image has an idle CPU consumption ~5%, so you can't have many concurrent images running in the same machine. Sure you can, a multi-core server isn't going to get maxed out by idle CPU consumption as each image will only do that on a single core; you can also reduce consumption on headless images by suspending the UI process which isn't needed getting you down to perhaps 2-3%. whilst 10 idle Pharo images will consume 50%. Only on a single CPU machine which isn't what you're going to have on a server. Running two images per core on a 12 core virtual server and you'll be sitting more like 5-6% idle which is totally fine. Spread that across 10 or 15 virtual servers and you can handle 1000 concurrent users just fine. -- Ramon Leon
Re: [Pharo-users] SandstoneDB for Pharo maintainer?
On 06/02/2016 09:26 AM, Udo Schneider wrote: All, I noticed that the most recent SandstoneDB fails most tests when using a disk based store. I have fixed the issue so that all tests are green again. I'm not sure how to proceed now though. I noticed that the StHub repository is public write. But I'm not sure if it's okay to simply push the changes/config. So who's the current maintainer or is there any other process? Thanks, It's open commit, feel free to commit your fixes; I'm no longer maintaining and left it open for all. -- Ramon Leon
Re: [Pharo-users] VM Crash after adding ram
On 07/30/2015 11:43 AM, Esteban Lorenzano wrote: Hi, did you try a fresh Pharo image (without loaded code)? ExternalObject and ExternalAddress are FFI so… problem*could* be there… no idea what can be happening, but well… it could be there:) cheers, Esteban After poking around the net a bit with some of the error messages I saw Inconsistency detected by ld.so: dl-open.c: 610: _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)-r_state == RT_CONSISTENT' failed! it was apparently some corrupted Ubuntu lib's that after running updates again and rebooting seem to have repaired themselves. The VM starting working fine after this last reboot which is admittedly the first reboot since I got the PC back up with the new amount of ram. So, apparently not a VM issue, thanks for the advice anyway. -- Ramon Leon
[Pharo-users] VM Crash after adding ram
: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance stack page bytes 4096 available headroom 3300 minimum unused headroom 3540 (no objects after the end of memory) Aborted (core dumped) -- Ramon Leon
Re: [Pharo-users] OrderedCollection remove:
On 04/01/2015 11:22 PM, Peter Uhnák wrote: col := #(1 2 3 4 5) asOrderedCollection. col do: [ :each | col remove: each. ]. col As a general rule in Smalltalk, a lot of hassle can be avoided avoiding loops. If you think you need a loop, stop and find a better way, it likely already exists, in this case as someone else already mentioned either #removeAll: or #removeSuchThat:. Smalltalk isn't procedural, loops aren't your bread and butter. -- Ramon Leon
