[Pharo-dev] Standardized nomenclature for feature requests
Hi there, Q: Is there a reason why Pharo (as a project) doesn't follow a standardized nomenclature for features/request as other communities does? So for instance something like PFR-005 (Pharo Feature Request) could be "Truly headless images", PFR-006 "Pharo Bootstrapping", etc. I can't really tell whether this would improve to the overall process, but I wanted to know if this was already debated by the board and dismissed, if it is something that wasn't considered at all, of if we have something equivalent and what it is. Regards, Language examples: JSR (Java Specification Requests) https://www.jcp.org/en/jsr/all PEP (Python Enhancement Proposals) https://www.python.org/dev/peps/ RFC (Rust, Request for Comments) https://github.com/rust-lang/rfcs Technologies: BIP (Bitcoin Improvement Proposal) https://github.com/bitcoin/bips EIP (Ethereum Improvement Proposal) https://eips.ethereum.org/ -- Esteban A. Maringolo signature.asc Description: OpenPGP digital signature
[Pharo-dev] ZnMimePart Disposition-Content spaces
Hi Sven, We encountered a ZnMimePart Content-Disposition header problem with a server expecting a space following the "form-data;" string. The diff here... https://www.diffchecker.com/ETIfCUzx * on the left shows the working request from the default command-line tool * on the right shows the non-working request from Pharo. The specifications are really unclear about the requirement or not for a space, so it may be reasonable to consider the fault lies with the server not being permissive enough, but I notice these examples all have space after semi colons... * https://tools.ietf.org/html/rfc7578 * https://www.ietf.org/rfc/rfc2388.txt so I wonder if this scenario might be widespread (and endemic to Rails apps which this was) and maybe its pragmatic to include the extra spaces to cut off potential issues (it took quite a while to isolate with the live service being HTTPS only.) Steps to reproduce are here... https://github.com/exercism/pharo/issues/96#issuecomment-421224203 In the meantime, once isolated it was simple to work around, but it was almost a show stopper, so I'm interested in your thoughts. cheers -ben
[Pharo-dev] Platform file encoding for FFI
Hi Esteban, Guille and Everyone, I haven't looked at using FFI much, however it is easy to imagine that different file encoding rules on different platforms will make writing FFI calls more difficult, i.e. some of the different formats are: - OSX uses Mac specific decomposed UTF8 encoding - Windows uses Wide Strings (16 bit Unicode characters) - Linux allows pretty much anything, but precomposed UTF8 is common Believe it or not, I'm still working on getting the FileAttributesPlugin working (file name encoding on Windows being the latest issue - the tests in Pharo need to be extended). Would it be useful for future FFI work to have primitives available which convert file names to and from the various platform specific formats? (Linux is basically a no-op, and Windows could be written in-image, but OSX requires the platform routines to be called). Cheers, Alistair
[Pharo-dev] [Pharo 7.0-dev] Build #1252: 22417 Decide about DateAndTimeDosEpochTest>>testToByDo
There is a new Pharo build available! The status of the build #1252 was: FAILURE. The Pull Request #1810 was integrated: "22417 Decide about DateAndTimeDosEpochTest>>testToByDo" Pull request url: https://github.com/pharo-project/pharo/pull/1810 Issue Url: https://pharo.fogbugz.com/f/cases/22417 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1252/
[Pharo-dev] [Pharo 7.0-dev] Build #1251: 22459-FileReferencecopyTo-deserves-a-much-better-comment
There is a new Pharo build available! The status of the build #1251 was: SUCCESS. The Pull Request #1807 was integrated: "22459-FileReferencecopyTo-deserves-a-much-better-comment" Pull request url: https://github.com/pharo-project/pharo/pull/1807 Issue Url: https://pharo.fogbugz.com/f/cases/22459 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1251/
[Pharo-dev] Confused about FileReference read/write streams
Hi, Since ever (or as far as I can remember), FileReference made a distinction between read and write streams, see #readStream[Do:] and #writeStream[Do:] - these return a ZnCharacterReadStream and ZnCharacterWriteStream in Pharo 7. Along the same lines, #binaryReadStream and #binaryWriteStream where introduced. However, the first returns a ZnBufferedReadStream (OK) while the latter returns a ZnBufferedReadWriteStream. Why ? I think it would be generally better if a standard ZnBufferedWriteStream where returned. ZnBufferedReadWriteStream is not a very pretty class to say the least, it also strikes me as confusing. What would break if we changed this ? If necessary there could be something like #readWriteStream[Do:] I guess. Sven
[Pharo-dev] [ANN] New Pharo 6.1 stable VM
Hi, Following what I had in my todo list for when coming back from ESUG, I promoted a new stable VM for Pharo 6.1. This is the VM that has been tested during almost two months for Pharo 7.0, so it should be fine, but let me know if there is any problem. Esteban
