[Pharo-users] Lightweight name spacing or shadowing - anything that can help me load conflicting code?
Hi - as I work through the different strands fo exercism (which has been a great project to kick different corners of Pharo) - I’ve hit an area where I’m wondering if there might be some useful tricks/techniques/ideas to help … Essentially - I want to make mentoring easier (so hopefully people on this list might consider being a Pharo Exercism mentor). While there are basic review tools on exercism.io - reading code in Tonel only gets you so far… So there is an endpoint for mentors to load in code (much like we already read in the exercises for users, and then use the TonelReader to parse and compile the code so its ready to run - a nice property of recent Pharo changes is that its quite happy to compile missing classes/methods and let you later fill those in, inside the debugger - it makes TDD awesome). However - it would be nice if mentors could have the current solutions loading in an image, and then could load in the users submission (via a tool hitting the endpoint - and doing the same TonelReader stuff). The issue of course is that you have a name clash - their solution and the reference solution. So I could possibly walk the ast of the parsed solution and adjust the names (putting a user prefix) - and possibly the refactoring tools will also let me detect references to those names and then let adjust those too (I also will have the thorny issue of extension methods - although its a rare edge case I could ignore). But I’m wondering if there is something neater that might work? Can I load these as “shadow classes/methods” somehow (when you browse Monticello package versions I recall you could see code in a browser - and I guess iceberg does that too?). This might work - although it doesn’t let me run the code and see any errors - but it might be good enough. Or is there some way of having a cheap alternate Smalltalk context where I can load that code so it doesn’t collide. I guess this is edging on full namespaces - but I think my problem might be more confined and possibly doable more easily (than a general namespace solution that has to work for everything). Anyone have any thoughts - pointers? I know namespaces is very controversial, but maybe this might be simpler? Tim
[Pharo-users] ldap, Pier3 & git migration
--- Begin Message --- Hi, In case someone can use it: I used Peters git migration tool for ... http://smalltalkhub.com/#!/~PharoExtras/LDAP/ ... and put it to: https://github.com/a2b-alb/PharoExtras-LDAP I don't know if this is the right place or if you would rather have it under ... https://github.com/pharo-contributions/ ... or somewhere else. - here the question: I started trying to do the same migration process for ... http://www.smalltalkhub.com/#!/~Pier/Pier3 ... but I failed on errors loading older mcz files: "instance of ByteString did not understand #peek" on: MCMczReader >> contentsForMember: (ZnInvalidUTF8: Illegal leading byte for utf-8 encoding) Is this wrong encoding or corrupted files ? How to treat these files ? -> Is just ignoring this majority of failing mcz files via migration ignoredFileNames: #() ok ? - As a workaround I then left the history versions behind and took only the newest mcz files. But I am not sure which package version "is in harmony" with the other ones... ;-) -> While trying out which versions of the ConfigurationOfPier3 load in a p7 image only the #stable one loaded without problems. The newer ones didn't. I did this by first loading as much pier3 dependencies (seaside, magritte, ...) from the new github repos. So I can then say ... onConflict: [ :e | e useLoaded ]; ... when loading pier3 from smaltalkhub. Can someone who knows pier3 better than me, give me a hint on which package versions combinations are the ones to go with ? -> Is to just start with the newest mcz files the way to go? Or should I use the #stable ConfigurationOfPier3 ? best, Albrecht --- End Message ---
Re: [Pharo-users] Pharo 7.0 image size
Ciao, this morning i started with an image of about 240 MB. I have 3 System Browser open ( for a long time ). I close all the System Browser and save the image. The image size after the save is about 131 MB. The new SpaceTally printSpaceAnalysis report: Class code space# instances inst space percent inst average size Array 4115561766 37353480 25.60 66.49 ByteString 2942249761 31313136 21.50 125.37 The Transcript entry reference basically does not change: ByteString allInstances select:[ :i | i includesSubstring: 'NETWORK' ] where 'NETWORK' is a string used in the methods to add Transcript entry Transcript show: .. NETWORK' ..' . The system found 2958ByteString instances( relative to the NETWORK ) The system found22655 ByteString instances( relative to the CASH ) Why are there many references in the system to the ByteString instances, created in the methods to report the data in Transcript ? Someone to considerations ? Thanks, Dario > Ciao, > > I thought that using Transcript as a report to analyze the operation of > the code was a good thing - solution. > > Unfortunately, however, the size of the image continues to increase ( > and I think it's due to the use of the transcript ) > > and i can not find the solution to avoid the problem. > > I could create a file to report everything about the operations code, > but then it becomes difficult to manage, or am i wrong? > > Other solutions - indications - references ? > > Thanks, > > Dario > >> Ciao, >> >> thanks. >> >> i have a Pharo 7.0 alpha build 1262. >> >> I development a Seaside application. >> >>> May be you have a lot of still open Seaside session, which if I remember >>> correctly are automatically shutdown after 10 min when not active. >>> >>> Looking at Seaside session instances may give clue. >> >> OK, i clear the seaside session with the relative seaside status >> Clear action. >> >> >> >> But the image size keeps increasing, without an apparent reason. >> >> The consideration that I can do and that in the method code i often use >> Transcript show: '.NETWORK | CASH | .' to check the correct >> functioning. >> >> With theSpaceTally printSpaceAnalysis i note: >> >> as of February 16th: >> >> Classcode space # instances >> inst space percent inst average size >> Array 4115 >> 656764 43904528 23.30 66.85 >> ByteString 2942 >> 233871 27527272 14.60117.70 >> >> >> as of March 4th >> Class code space# instances >> inst space percentinst average size >> Array 4115837017 >> 50564552 23.4060.41 >> ByteString 2942 >> 266620 31933216 14.80 119.77 >> >> Now i do: >> >> ByteString allInstances select:[ :i | i >> includesSubstring: 'NETWORK' ] >> >> where 'NETWORK' is a string used in the Transcript show: .. >> NETWORK' ..' report entry. >> >> >> The system found 3214 ByteString instances( relative to >> the NETWORK ) >> >> The system found 22650 ByteString instances( >> relative to the CASH ) >> >> The system found .. >> >> >> Because ? >> >> >> Does the system remember something about the string >> create for the Transcript show: entry ? >> >> I need to reset something? >> >> How can I analyze the situation? >> >> I follow some aByteString entry with the >> pointersTo method >> >> but for now I have not found the solution. >> >> >> >> Thanks, >> >> Dario >> >> > >
Re: [Pharo-users] Pharo 7.0 image size
Ciao, this morning i started with an image of about 240 MB. I have 3 System Browser open ( for a long time ). I close all the System Browser and save the image. The image size after the save is about 131 MB. The new SpaceTally printSpaceAnalysis report: Class code space# instances inst space percent inst average size Array 4115561766 37353480 25.60 66.49 ByteString 2942249761 31313136 21.50 125.37 The Transcript entry reference basically does not change: ByteString allInstances select:[ :i | i includesSubstring: 'NETWORK' ] where 'NETWORK' is a string used in the methods to add Transcript entry Transcript show: .. NETWORK' ..' . The system found 2958ByteString instances( relative to the NETWORK ) The system found22655 ByteString instances( relative to the CASH ) Why are there many references in the system to the ByteString instances, created in the methods to report the data in Transcript ? Someone to considerations ? Thanks, Dario > Ciao, > > I thought that using Transcript as a report to analyze the operation of > the code was a good thing - solution. > > Unfortunately, however, the size of the image continues to increase ( > and I think it's due to the use of the transcript ) > > and i can not find the solution to avoid the problem. > > I could create a file to report everything about the operations code, > but then it becomes difficult to manage, or am i wrong? > > Other solutions - indications - references ? > > Thanks, > > Dario > >> Ciao, >> >> thanks. >> >> i have a Pharo 7.0 alpha build 1262. >> >> I development a Seaside application. >> >>> May be you have a lot of still open Seaside session, which if I remember >>> correctly are automatically shutdown after 10 min when not active. >>> >>> Looking at Seaside session instances may give clue. >> >> OK, i clear the seaside session with the relative seaside status >> Clear action. >> >> >> >> But the image size keeps increasing, without an apparent reason. >> >> The consideration that I can do and that in the method code i often use >> Transcript show: '.NETWORK | CASH | .' to check the correct >> functioning. >> >> With theSpaceTally printSpaceAnalysis i note: >> >> as of February 16th: >> >> Classcode space # instances >> inst space percent inst average size >> Array 4115 >> 656764 43904528 23.30 66.85 >> ByteString 2942 >> 233871 27527272 14.60117.70 >> >> >> as of March 4th >> Class code space# instances >> inst space percentinst average size >> Array 4115837017 >> 50564552 23.4060.41 >> ByteString 2942 >> 266620 31933216 14.80 119.77 >> >> Now i do: >> >> ByteString allInstances select:[ :i | i >> includesSubstring: 'NETWORK' ] >> >> where 'NETWORK' is a string used in the Transcript show: .. >> NETWORK' ..' report entry. >> >> >> The system found 3214 ByteString instances( relative to >> the NETWORK ) >> >> The system found 22650 ByteString instances( >> relative to the CASH ) >> >> The system found .. >> >> >> Because ? >> >> >> Does the system remember something about the string >> create for the Transcript show: entry ? >> >> I need to reset something? >> >> How can I analyze the situation? >> >> I follow some aByteString entry with the >> pointersTo method >> >> but for now I have not found the solution. >> >> >> >> Thanks, >> >> Dario >> >> > >
[Pharo-users] The best way to construct a file/url path handling misplaced $/ chars
I’m sure we have something in the image that deals with this - but if writing a generic http retriever and wanting to correctly cope with constructing resource paths where the base path may or may not have a trailing /, and the resource path may or may not have a leading / Basically - magically handle /name//resourse /name///resource I’m sure we have something simple - the best I could see was to abuse Path like: (Path from: basePath, '/', resourcePath) pathString Is this a good way to do it? Tim
Re: [Pharo-users] The best way to construct a file/url path handling misplaced $/ chars
Not sure but I would use ZnUrl
ZnUrl new
scheme: #http;
host: NetNameResolver loopBackName;
addPathSegments: #('echo' 'foo');
yourself
Making sure Path segments do not contain separator…
Hth,
Cédrick
> Le 8 mars 2019 à 12:33, Tim Mackinnon a écrit :
>
> I’m sure we have something in the image that deals with this - but if writing
> a generic http retriever and wanting to correctly cope with constructing
> resource paths where the base path may or may not have a trailing /, and the
> resource path may or may not have a leading /
>
> Basically - magically handle
>
> /name//resourse
> /name///resource
>
>
> I’m sure we have something simple - the best I could see was to abuse Path
> like:
>
> (Path from: basePath, '/', resourcePath) pathString
>
> Is this a good way to do it?
>
> Tim
Re: [Pharo-users] The best way to construct a file/url path handling misplaced $/ chars
'/foo//' copyWithoutAll: '/'
> Le 8 mars 2019 à 12:40, Cédrick Béler a écrit :
>
> Not sure but I would use ZnUrl
>
> ZnUrl new
> scheme: #http;
> host: NetNameResolver loopBackName;
> addPathSegments: #('echo' 'foo');
> yourself
>
> Making sure Path segments do not contain separator…
>
> Hth,
>
> Cédrick
>
>
>
>> Le 8 mars 2019 à 12:33, Tim Mackinnon a écrit :
>>
>> I’m sure we have something in the image that deals with this - but if
>> writing a generic http retriever and wanting to correctly cope with
>> constructing resource paths where the base path may or may not have a
>> trailing /, and the resource path may or may not have a leading /
>>
>> Basically - magically handle
>>
>> /name//resourse
>> /name///resource
>>
>>
>> I’m sure we have something simple - the best I could see was to abuse Path
>> like:
>>
>> (Path from: basePath, '/', resourcePath) pathString
>>
>> Is this a good way to do it?
>>
>> Tim
>
[Pharo-users] What is the pharo days code?
Anyone know what is my code to use for Pharo Days registration? I got my member confirmation but have no idea what the code is all about that it wants for the Pharo days registration? (I recall this happening a few years ago but didn’t pay attention) Any ideas? Tim
Re: [Pharo-users] The best way to construct a file/url path handling misplaced $/ chars
I don't know whether you want to build just "paths" or valid URIs, if it's the latter, I'd suggest ZnUrl as well. '/name/' asPath / 'resource'. -> /name/resource '/name/' asPath / '/resource'. -> /resource (which is correct) '/name/' asUrl / '/resource' -> /name//resource (which is correct as well). The other way is to use path segments, as Cédrick suggested. Regards, Esteban A. Maringolo El vie., 8 mar. 2019 a las 8:34, Tim Mackinnon () escribió: > I’m sure we have something in the image that deals with this - but if > writing a generic http retriever and wanting to correctly cope with > constructing resource paths where the base path may or may not have a > trailing /, and the resource path may or may not have a leading / > > Basically - magically handle > > /name//resourse > /name///resource > > > I’m sure we have something simple - the best I could see was to abuse Path > like: > > (Path from: basePath, '/', resourcePath) pathString > > Is this a good way to do it? > > Tim >
Re: [Pharo-users] ldap, Pier3 & git migration
I wasn't aware of LDAP support in Pharo. Thanks for porting it. Wouldn't it be better to call the repo "pharo-ldap"? When my repositories are Pharo specific and don't have a fancy project name I name them "pharo-something", e.g. "pharo-couchdb", "pharo-base58", "pharo-bip39mnemonic", etc. Regards, Esteban A. Maringolo El vie., 8 mar. 2019 a las 8:45, Albrecht Baur via Pharo-users (< pharo-users@lists.pharo.org>) escribió: > Hi, In case someone can use it: I used Peters git migration tool for ... > http://smalltalkhub.com/#!/~PharoExtras/LDAP/ > ... and put it to: > https://github.com/a2b-alb/PharoExtras-LDAP > > I don't know if this is the right place or if you would rather have it > under ... > https://github.com/pharo-contributions/ > ... or somewhere else. > > - here the question: > I started trying to do the same migration process for ... > http://www.smalltalkhub.com/#!/~Pier/Pier3 > ... but I failed on errors loading older mcz files: > > "instance of ByteString did not understand #peek" > on: MCMczReader >> contentsForMember: > (ZnInvalidUTF8: Illegal leading byte for utf-8 encoding) > > Is this wrong encoding or corrupted files ? > How to treat these files ? -> Is just ignoring this majority of failing > mcz files via migration ignoredFileNames: #() > ok ? > > - > As a workaround I then left the history versions behind and took only > the newest mcz files. But I am not sure which package version "is in > harmony" with the other ones... ;-) > -> While trying out which versions of the ConfigurationOfPier3 load in a > p7 image only the #stable one loaded without problems. The newer ones > didn't. > > I did this by first loading as much pier3 dependencies (seaside, > magritte, ...) from the new github repos. So I can then say ... > onConflict: [ :e | e useLoaded ]; > ... when loading pier3 from smaltalkhub. > > Can someone who knows pier3 better than me, give me a hint on which > package versions combinations are the ones to go with ? > -> Is to just start with the newest mcz files the way to go? Or should I > use the #stable ConfigurationOfPier3 ? > > best, > Albrecht > > >
[Pharo-users] Read and parse maildir (offlineimap) files
Hi Everyone, I'd like to be able to parse and read the mail files as saved by offlineimap, i.e. in maildir format (one message per file). Does anyone know of any existing libraries in Pharo? Thanks very much, Alistair
Re: [Pharo-users] ldap, Pier3 & git migration
--- Begin Message --- sorry for double posting in dev and users ... I pushed it to https://github.com/pharo-contributions/LDAP There it fits better (and we have the 'pharo' at least inside the path...) Best Albrecht On 08.03.19 15:05, Esteban Maringolo wrote: I wasn't aware of LDAP support in Pharo. Thanks for porting it. Wouldn't it be better to call the repo "pharo-ldap"? When my repositories are Pharo specific and don't have a fancy project name I name them "pharo-something", e.g. "pharo-couchdb", "pharo-base58", "pharo-bip39mnemonic", etc. Regards, Esteban A. Maringolo El vie., 8 mar. 2019 a las 8:45, Albrecht Baur via Pharo-users (mailto:pharo-users@lists.pharo.org>>) escribió: Hi, In case someone can use it: I used Peters git migration tool for ... http://smalltalkhub.com/#!/~PharoExtras/LDAP/ ... and put it to: https://github.com/a2b-alb/PharoExtras-LDAP I don't know if this is the right place or if you would rather have it under ... https://github.com/pharo-contributions/ ... or somewhere else. - here the question: I started trying to do the same migration process for ... http://www.smalltalkhub.com/#!/~Pier/Pier3 ... but I failed on errors loading older mcz files: "instance of ByteString did not understand #peek" on: MCMczReader >> contentsForMember: (ZnInvalidUTF8: Illegal leading byte for utf-8 encoding) Is this wrong encoding or corrupted files ? How to treat these files ? -> Is just ignoring this majority of failing mcz files via migration ignoredFileNames: #() ok ? - As a workaround I then left the history versions behind and took only the newest mcz files. But I am not sure which package version "is in harmony" with the other ones... ;-) -> While trying out which versions of the ConfigurationOfPier3 load in a p7 image only the #stable one loaded without problems. The newer ones didn't. I did this by first loading as much pier3 dependencies (seaside, magritte, ...) from the new github repos. So I can then say ... onConflict: [ :e | e useLoaded ]; ... when loading pier3 from smaltalkhub. Can someone who knows pier3 better than me, give me a hint on which package versions combinations are the ones to go with ? -> Is to just start with the newest mcz files the way to go? Or should I use the #stable ConfigurationOfPier3 ? best, Albrecht --- End Message ---
Re: [Pharo-users] Read and parse maildir (offlineimap) files
Hi Alistair, This looks like what I’d like to have (parsing emails). I’d better like an IMAP Client but using offlinmap might be an option. Will look at it. Do you have an exemple of milder format files ? Cheers, Cédrick > Le 8 mars 2019 à 15:49, Alistair Grant a écrit : > > Hi Everyone, > > I'd like to be able to parse and read the mail files as saved by > offlineimap, i.e. in maildir format (one message per file). > > Does anyone know of any existing libraries in Pharo? > > Thanks very much, > Alistair >
Re: [Pharo-users] Read and parse maildir (offlineimap) files
Hi Cédrick, On Fri, 8 Mar 2019 at 16:12, Cédrick Béler wrote: > > Hi Alistair, > > This looks like what I’d like to have (parsing emails). I’d better like an > IMAP Client but using offlinmap might be an option. > > Will look at it. > > Do you have an exemple of milder format files ? Attached is the email you sent. I found https://github.com/codeZeilen/SMailDir but it is written for Squeak and doesn't load cleanly in Pharo (I haven't actually done anything with it yet). Cheers, Alistair > > Le 8 mars 2019 à 15:49, Alistair Grant a écrit : > > > > Hi Everyone, > > > > I'd like to be able to parse and read the mail files as saved by > > offlineimap, i.e. in maildir format (one message per file). > > > > Does anyone know of any existing libraries in Pharo? > > > > Thanks very much, > > Alistair > > > > Delivered-To: akgrant0...@gmail.com Received: by 2002:adf:f60c:0:0:0:0:0 with SMTP id t12csp8602606wrp; Fri, 8 Mar 2019 07:12:35 -0800 (PST) X-Google-Smtp-Source: APXvYqyBULvLpmGOcHmSY32oNpah6+9Q1+jsoGuCWrldlE+6N1ssoDlcF4sOe56oCvZf45IQq8Tz X-Received: by 2002:a37:7ac6:: with SMTP id v189mr1718893qkc.205.1552057955857; Fri, 08 Mar 2019 07:12:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1552057955; cv=none; d=google.com; s=arc-20160816; b=nWzIqH0rl4J/gIywtYSkjB0MpJKZmVEAij9WfoNQ+7w8TpsTvHZ2rO6RrD2JBV938b /cr80WR/f/ThOF9Zio63/dweitly+DXR1dBAXCXG8h1ZbQsn4uwo8LoJSIE7diVA31kh oRqXv1KaS1PegIfpt3VnkjlEYyIoyUzX2GuA5bniS109AP5NA2Ccs0/K6nKhJr70E6l1 mQqR/ttf3wc91wIv6VKfW4u5/a4gA3Fy0BXxjCpZNAfeVK6LNk6oTyXiDVcG2ewrEzam ojsspfJixRk9DDQ4/6mDrQeBNT+a3olgi7Yvhvu1rRZpS6Jya+F1u0vkKoEQi2hG3lhA fyqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence:subject:message-id :in-reply-to:to:references:date:mime-version :content-transfer-encoding:from:dkim-signature; bh=JLBqlHE8xrteXdPe7tOJaVhkGilsOxLBhklK69nyufI=; b=ldgX5puIMSXDWv48kjErgF1ObLYmtqQx//YsZJIQISD7PPkLzw+baSvf/REjrwLc9v CsQMfYOPtDrYOv6nDJjuKd5+I6pP/WR5kahXt6Qbud781AA4wCEonhvHEanqEkuJTL2p KDIW163ExeOw7O4slhgrwtbyvzqIGVp4dVunHyO/oLqmdrvyrPx97nGkX4a1J9OMYAHe VCqd/dRLAWVS77ZnskCUnzGN0fmC8HwIt+dfY4T5O0ea9HXdfKbUbQ1crf8gF3hZ8Vhp sgfBTNIMbl7TsJKC4X+5/oXF3mguBoj7No+IKO3xUXty/44+VxAsi/HTJdufU96Lio5S ZvHw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=vQv+2Amn; spf=neutral (google.com: 172.104.12.73 is neither permitted nor denied by best guess record for domain of pharo-users-boun...@lists.pharo.org) smtp.mailfrom=pharo-users-boun...@lists.pharo.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from mm1.emwd.com (mm1.emwd.com. [172.104.12.73]) by mx.google.com with ESMTPS id 7si5019284qto.247.2019.03.08.07.12.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Mar 2019 07:12:35 -0800 (PST) Received-SPF: neutral (google.com: 172.104.12.73 is neither permitted nor denied by best guess record for domain of pharo-users-boun...@lists.pharo.org) client-ip=172.104.12.73; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=vQv+2Amn; spf=neutral (google.com: 172.104.12.73 is neither permitted nor denied by best guess record for domain of pharo-users-boun...@lists.pharo.org) smtp.mailfrom=pharo-users-boun...@lists.pharo.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from [::1] (port=40352 helo=mm1.emwd.com) by mm1.emwd.com with esmtp (Exim 4.91) (envelope-from ) id 1h2HAp-0006Hr-3J; Fri, 08 Mar 2019 10:12:35 -0500 Received: from mail-wm1-f53.google.com ([209.85.128.53]:36403) by mm1.emwd.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h2HAn-00064x-Iq for pharo-users@lists.pharo.org; Fri, 08 Mar 2019 10:12:33 -0500 Received: by mail-wm1-f53.google.com with SMTP id j125so12764950wmj.1 for ; Fri, 08 Mar 2019 07:12:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=JLBqlHE8xrteXdPe7tOJaVhkGilsOxLBhklK69nyufI=; b=vQv+2Amn6rfPv/JGQO38SvNlrlQxsnUjIUHZSRiYo8Eh9GrbRAP8W3tuVli7ERsfPM J9x3+AEebW37e/ir7BLvoTbzkh9bJfF8OXR7MRTfskaQJpJNGQhI7wuQ9IVhAC01SfRK yvVatoe1lroT0dnLDgKgiFoVO5MaZ3JiYBJMnTD8S5MtQ4Ubzjwda/X+CuZ51GI+9p8s t6y3Xh//Ujmtk/D0TtomuZuf/U1ocFNPBig9fyXV5/p34vAeH+Qo/ZwKaf6lPq3wtGRm GLjsY8WTlfDYTmSR8e0w/ezjz+5XUqzrKiNr064ga5CMTyJVCwLfqc1U+TcY0TEAcOHd yuvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:conte
Re: [Pharo-users] Read and parse maildir (offlineimap) files
It's a common shell script lab assignment to be able to parse this format (RFC 822). Unix 101 level. A bit tricky in practice, because the format has a strong dependency on the blank line between the header part and the email content... Technically, maildir only refers to the directory/files organisation, not the format of an email inside each file. Emails with attachments can create headaches for quick and dirty scan, because they appear as text files containing binary data a few MBs long... If you happen to have a backtracking RE or parser on it, you'll kill your image. Thierry Le ven. 8 mars 2019 à 16:23, Alistair Grant a écrit : > > Hi Cédrick, > > On Fri, 8 Mar 2019 at 16:12, Cédrick Béler wrote: > > > > Hi Alistair, > > > > This looks like what I’d like to have (parsing emails). I’d better like an > > IMAP Client but using offlinmap might be an option. > > > > Will look at it. > > > > Do you have an exemple of milder format files ? > > Attached is the email you sent. > > I found https://github.com/codeZeilen/SMailDir but it is written for > Squeak and doesn't load cleanly in Pharo (I haven't actually done > anything with it yet). > > Cheers, > Alistair > > > > > Le 8 mars 2019 à 15:49, Alistair Grant a écrit : > > > > > > Hi Everyone, > > > > > > I'd like to be able to parse and read the mail files as saved by > > > offlineimap, i.e. in maildir format (one message per file). > > > > > > Does anyone know of any existing libraries in Pharo? > > > > > > Thanks very much, > > > Alistair > > > > > > >
Re: [Pharo-users] ldap, Pier3 & git migration
On Fri, 8 Mar 2019 at 22:59, Albrecht Baur via Pharo-users < pharo-users@lists.pharo.org> wrote: > sorry for double posting in dev and users ... > > I pushed it to > > https://github.com/pharo-contributions/LDAP > > There it fits better (and we have the 'pharo' at least inside the path...) > The case to cater for is the common action of someone forking it under their account. e.g. https://github.com/bencoman/LDAP is a bit misleading. Better to be https://github.com/bencoman/pharo-ldap cheers -ben > Best > > Albrecht > On 08.03.19 15:05, Esteban Maringolo wrote: > > I wasn't aware of LDAP support in Pharo. Thanks for porting it. > > Wouldn't it be better to call the repo "pharo-ldap"? > > When my repositories are Pharo specific and don't have a fancy project > name I name them "pharo-something", e.g. "pharo-couchdb", "pharo-base58", > "pharo-bip39mnemonic", etc. > > Regards, > > Esteban A. Maringolo > > > El vie., 8 mar. 2019 a las 8:45, Albrecht Baur via Pharo-users (< > pharo-users@lists.pharo.org>) escribió: > >> Hi, In case someone can use it: I used Peters git migration tool for ... >> http://smalltalkhub.com/#!/~PharoExtras/LDAP/ >> ... and put it to: >> https://github.com/a2b-alb/PharoExtras-LDAP >> >> I don't know if this is the right place or if you would rather have it >> under ... >> https://github.com/pharo-contributions/ >> ... or somewhere else. >> >> - here the question: >> I started trying to do the same migration process for ... >> http://www.smalltalkhub.com/#!/~Pier/Pier3 >> ... but I failed on errors loading older mcz files: >> >> "instance of ByteString did not understand #peek" >> on: MCMczReader >> contentsForMember: >> (ZnInvalidUTF8: Illegal leading byte for utf-8 encoding) >> >> Is this wrong encoding or corrupted files ? >> How to treat these files ? -> Is just ignoring this majority of failing >> mcz files via migration ignoredFileNames: #() >> ok ? >> >> - >> As a workaround I then left the history versions behind and took only >> the newest mcz files. But I am not sure which package version "is in >> harmony" with the other ones... ;-) >> -> While trying out which versions of the ConfigurationOfPier3 load in a >> p7 image only the #stable one loaded without problems. The newer ones >> didn't. >> >> I did this by first loading as much pier3 dependencies (seaside, >> magritte, ...) from the new github repos. So I can then say ... >> onConflict: [ :e | e useLoaded ]; >> ... when loading pier3 from smaltalkhub. >> >> Can someone who knows pier3 better than me, give me a hint on which >> package versions combinations are the ones to go with ? >> -> Is to just start with the newest mcz files the way to go? Or should I >> use the #stable ConfigurationOfPier3 ? >> >> best, >> Albrecht >> >> >>
Re: [Pharo-users] Alternative to NautilusMethodSelected in Calypso
Hi Gustavo, Is MacroRecorder available for Pharo 7? Cheers, Hernán El mar., 4 dic. 2018 a las 14:47, Gustavo Santos () escribió: > > Hello, > > I'm trying to upgrade MacroRecorder to Pharo7. > I used NautilusClassSelected and NautilusMethodSelected announcements to > apply a macro in a given class or method right after the developer clicks on > the browser. Something like > > AbstractNautilusPlugin subclass: #MRNautilusPlugin ... > > registerTo: aModel > aModel announcer weak > when: NautilusClassSelected send: #entitySelected: to: self; > when: NautilusMethodSelected send: #entitySelected: to: self. > > How can I do the same with Calypso? > > Cheers, > -- > Gustavo Santos > http://gustavojss.github.io/
[Pharo-users] NeoCSV Logging
Is there anything built-in? I have a particularly long file and want to give updates so users don't thing the image has frozen. If not, thinking I'll subclass reader and override #do: - Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Re: [Pharo-users] NeoCSV Logging
You mean something like signal progress notifications ? No that does not exist, indeed you can roll your own, counting every record read and then do something every N times. > On 8 Mar 2019, at 20:29, Sean P. DeNigris wrote: > > Is there anything built-in? I have a particularly long file and want to give > updates so users don't thing the image has frozen. > > If not, thinking I'll subclass reader and override #do: > > > > - > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >
[Pharo-users] FUEL serialization to a file
Hi everyone, after playing with FUEL in-memory (byte arrays) for a while, I am ready to attack files. But... that's not so easy. At https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/Fuel/Fuel.html I find the basic exxample 'demo.fuel' asFileReference writeStreamDo: [ :aStream | FLSerializer newDefault serialize: 'stringToSerialize' on: aStream binary ]. It fails because ZnCharacterWriteStream does not understand #binary. Browsing around a bit, I found another way: 'demo.fuel' asFileReference writeStreamDo: [ :aStream | FLSerializer newDefault serialize: 'stringToSerialize' on: aStream binary ]. This works fine, the aStream being a ZnBufferedWriteStream. But on larger objects, it ends up failing in FLBufferedWriteStream >> #nextBytePutAll: which sends the message stream nextBytesPutAll: collection But ZnBufferedWriteStream does not understand nextBytesPutAll: because it is not a subclass of Stream for whatever reason. Some further browing showed deprecated classes FileStream etc., and I kind of suspect that file streams in Pharo were changed at some point but FUEL still expects the old behavior. Does anyone have an idea how to fix this, or work around it? Thanks in advance, Konrad
Re: [Pharo-users] FUEL serialization to a file
Hmmm - yesterday I had someone serialise their debug stack (the top right menu bar action) to a file and send it to me and it worked treat - so I wonder what the difference is? Tim Sent from my iPhone > On 8 Mar 2019, at 20:22, Konrad Hinsen wrote: > > Hi everyone, > > after playing with FUEL in-memory (byte arrays) for a while, I am ready > to attack files. But... that's not so easy. > > At > https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/Fuel/Fuel.html > I find the basic exxample > > 'demo.fuel' asFileReference writeStreamDo: [ :aStream | > FLSerializer newDefault > serialize: 'stringToSerialize' > on: aStream binary ]. > > It fails because ZnCharacterWriteStream does not understand #binary. > > Browsing around a bit, I found another way: > > 'demo.fuel' asFileReference writeStreamDo: [ :aStream | > FLSerializer newDefault > serialize: 'stringToSerialize' > on: aStream binary ]. > > This works fine, the aStream being a ZnBufferedWriteStream. But on > larger objects, it ends up failing in > >FLBufferedWriteStream >> #nextBytePutAll: > > which sends the message > >stream nextBytesPutAll: collection > > But ZnBufferedWriteStream does not understand nextBytesPutAll: because > it is not a subclass of Stream for whatever reason. > > Some further browing showed deprecated classes FileStream etc., and I > kind of suspect that file streams in Pharo were changed at some point > but FUEL still expects the old behavior. > > Does anyone have an idea how to fix this, or work around it? > > Thanks in advance, > Konrad >
Re: [Pharo-users] FUEL serialization to a file
FUEL is a binary serialiser, in the new Pharo 7 stream approach, a stream is
either binary or textual, not both, nor can they be switched on the fly.
FileLocator temp / 'test.fuel' binaryWriteStreamDo: [ :out | FLSerializer
newDefault serialize: { 'Foo'. #bar. Float pi. 42 } on: out ].
FileLocator temp / 'test.fuel' binaryReadStreamDo: [ :in | (FLMaterializer
newDefault materializeFrom: in) root ].
> On 8 Mar 2019, at 21:22, Konrad Hinsen wrote:
>
> Hi everyone,
>
> after playing with FUEL in-memory (byte arrays) for a while, I am ready
> to attack files. But... that's not so easy.
>
> At
> https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/Fuel/Fuel.html
> I find the basic exxample
>
> 'demo.fuel' asFileReference writeStreamDo: [ :aStream |
> FLSerializer newDefault
> serialize: 'stringToSerialize'
> on: aStream binary ].
>
> It fails because ZnCharacterWriteStream does not understand #binary.
>
> Browsing around a bit, I found another way:
>
> 'demo.fuel' asFileReference writeStreamDo: [ :aStream |
> FLSerializer newDefault
> serialize: 'stringToSerialize'
> on: aStream binary ].
>
> This works fine, the aStream being a ZnBufferedWriteStream. But on
> larger objects, it ends up failing in
>
>FLBufferedWriteStream >> #nextBytePutAll:
>
> which sends the message
>
>stream nextBytesPutAll: collection
>
> But ZnBufferedWriteStream does not understand nextBytesPutAll: because
> it is not a subclass of Stream for whatever reason.
>
> Some further browing showed deprecated classes FileStream etc., and I
> kind of suspect that file streams in Pharo were changed at some point
> but FUEL still expects the old behavior.
>
> Does anyone have an idea how to fix this, or work around it?
>
> Thanks in advance,
> Konrad
>
Re: [Pharo-users] FUEL serialization to a file
Sven Van Caekenberghe writes:
> FUEL is a binary serialiser, in the new Pharo 7 stream approach, a
> stream is either binary or textual, not both, nor can they be switched
> on the fly.
OK, thanks for confirming my suspicion that there was a change in Pharo.
> FileLocator temp / 'test.fuel' binaryWriteStreamDo: [ :out | FLSerializer
> newDefault serialize: { 'Foo'. #bar. Float pi. 42 } on: out ].
So what I have been using is correct.
Tim Mackinnon writes:
> Hmmm - yesterday I had someone serialise their debug stack (the top
> right menu bar action) to a file and send it to me and it worked treat
> - so I wonder what the difference is?
The problem I have occurs in buffering code. I suspect that it happens
as a function of the size distribution of the objects that are
serialized.
The problem is best analyzed by looking at the implementors of
#nextBytesPutAll:. That's an extension method that Fuel puts on the
Stream hierarchy, including its own class FLBufferedWriteStream where
the method contains the lines
collection size > (self buffer size / 2)
ifTrue: [ stream nextBytesPutAll: collection ]
ifFalse: [ self nextBytesPutAll: collection ]
In the second line, it sends nextBytesPutAll: to the unbuffered
stream. Which should be fine if it inherits from Stream. But
ZnBufferedWriteStream does not inherit from Stream.
I tried unraveling the construction of ZnBufferedWriteStream, to use
directly its underlying stream:
| ref stream |
ref := FileLocator temp / 'test.fuel'.
stream := ref fileSystem binaryWriteStreamOn: ref path.
[ FLSerializer newDefault serialize: { 'Foo'. #bar. Float pi. 42 }
on: stream ]
ensure: [ stream close ]
On a standard file, that yields a BinaryFileStream, and everything works
fine. But for my test cases I use a MemoryFileSystem, and then I get
the same problem again - MemoryFileWriteStream does not inherit from
Stream either.
I wonder what's wrong with the Stream class - why are there stream-type
classes that don't inherit from it?
Konrad.
