Hi Jukka,
On 2013-11-16 1:48 AM, Jukka Tuominen wrote:
> I was happy to hear about the package Marketplace [...], and I wonder
> if it could be used as a starting point?
Marketplace is still in flux. It could be useful as a way of forcing
yourself to really *commit* to the idea of pub/sub-all-the
Pre-caveats:
- Maybe this has been discussed before?
- This is true (IIUC) of the old Planet as well as the new package system.
- Maybe it's true of every package system.
With that said:
Technically, to maintain backward compatibility, a package should
_never_ `provide` a new name in an existing
I notice that the current version of Racket has stopped working on my Snow
Leopard machine in the last week or so — whether built from Git source or
installed with the nightly build installer.
Are the previous nightly builds archived to any degree? Which would at least
let me narrow down the sp
On Mon, Nov 18, 2013 at 10:22 AM, Greg Hendershott
wrote:
> p.s. Even in the case where I _know_ that `foo` will soon be provided
> in other-package -- let's say I submit a PR for my handy `foo` to be
> added to that package, with a view toward eventually dropping my own
> version -- the timing co
I explicitly mentioned this in the RacketCon talk. PLT generally does
not consider new exports to be backwards incompatible, even though in
principle it is.
I think the only-in/prefix-in idea is the right way to go, but it is
pretty painful. There are a few ways to make it simpler. I have a
"inter
I'll elaborate on Jay's answer --- because I had written most of this
by the time I saw Jay's post, and I think this version of the answer
adds a little.
Despite various efforts, we have no technical solution here, so far:
* Always using `only-in` or `prefix-in` seems too painful. (We know
th
I did "only-in" for a while in a large system, proactively, for some of
the reasons you mention. I later decided it was a tedious and
ugly-looking pain in the butt with no actual benefit shown after years
in practice.
I currently try to have reusable modules provide names that are
reasonably
> I explicitly mentioned this in the RacketCon talk.
Sorry, I was distracted because I was on-deck to give my talk next. :)
> PLT generally does
> not consider new exports to be backwards incompatible, even though in
> principle it is.
In general I agree with that. Certainly when I'm building th
In my experience, using plain require and later adding 'except-in' when a
service module decides to widen its interface is a much simpler approach than
pre-emptively using 'prefix-in' or 'only-in', especially if you need (almost)
everything from a (possibly large) library. -- Matthias
__
Greg Hendershott writes:
> Pre-caveats:
> - Maybe this has been discussed before?
> - This is true (IIUC) of the old Planet as well as the new package system.
> - Maybe it's true of every package system.
It's certainly a problem with many package systems.
I have run into the exact situation
> In my experience, using plain require and later adding 'except-in' when a
> service module decides to widen its interface is a much simpler approach
> than pre-emptively using 'prefix-in' or 'only-in', especially if you need
> (almost) everything from a (possibly large) library. -- Matthias
In a function that permits liberal inputs, I often find that the input
processing I do in a contract is duplicated at the beginning of the body of the
function. Is this avoidable?
Certain functions want to be liberal with input because there are multiple
common ways to represent the data. For i
I am with you on the scenario but I think 'early failure' is good because a
mostly compatible upgrade (widening the API) may have introduced other small
changes and all packages between yours and the modified one may suffer. So I
would love to see that our social processes push people to repair
I think the proper interface to offer is to separate the interfaces:
-- one function that works on normalized interfaces and for that you use
rgb-color/c
-- other function(s) that work on liberal inputs and clients know they may pay
the cost for double-normalization
On Nov 18, 2013,
Social processes are good. Participants should try to find
mutually-agreeable balances between proactive and reactive in their
interdependencies.
Some people (myself included) are likely to be scared if some third
party on whom we depend seems to take *too much* of an attitude of "it's
OK if
On 11/18/2013 12:03 PM, Matthew Butterick wrote:
In a function that permits liberal inputs, I often find that the input
processing I do in a contract is duplicated at the beginning of the body of the
function. Is this avoidable?
Certain functions want to be liberal with input because there are
Hi Tony,
> On 18.11.2013, at 16.13, Tony Garnock-Jones wrote:
>
> Hi Jukka,
>
>> On 2013-11-16 1:48 AM, Jukka Tuominen wrote:
>> I was happy to hear about the package Marketplace [...], and I wonder
>> if it could be used as a starting point?
>
> Marketplace is still in flux. It could be usef
On 2013-11-18 09:03:19 -0800, Matthew Butterick wrote:
> In a function that permits liberal inputs, I often find that the input
> processing I do in a contract is duplicated at the beginning of the
> body of the function. Is this avoidable?
FWIW, I came across the same issue when writing contracts
Dear Racket-Users,
while using ffi-lib to invoke the SDL2 and SDL2_mixer libraries (on Mac
OS X 10.6.8), I came across a peculiar problem:
the latter requires the former and does so by depending on its location
at "@rpath/SDL2.framework/Versions/A/SDL2".
In the context of Racket, @rpath appears
You can use `install_name_tool` to change the path in a copy of
`SDL2_mixer` so that it uses `@executable_path/...` instead of
`@rpath/...`.
At Mon, 18 Nov 2013 20:30:50 +0100, Philipp Dikmann wrote:
> Dear Racket-Users,
>
> while using ffi-lib to invoke the SDL2 and SDL2_mixer libraries (on Mac
> This is easily doable with a teachpack:
>
> 1. how to create a teachpack
> http://docs.racket-lang.org/htdp/index.html?q=teachpack
>
> 2. the key is to document the (a) structure type definition and (b) the
> data definition you export.
Any recommendations for delivering the documentat
> To ensure that an input string represents a valid address, the contract
> needs to parse the string. The constructor for the address structure
> also needs to parse the string to get the data, so it's redundant.
>
> (I didn't come up with a nice solution though)
BTW it's not that I want to abu
On Nov 18, 2013, at 3:15 PM, Norman Ramsey wrote:
>> This is easily doable with a teachpack:
>>
>> 1. how to create a teachpack
>> http://docs.racket-lang.org/htdp/index.html?q=teachpack
>>
>> 2. the key is to document the (a) structure type definition and (b) the
>> data definition you expo
2013/11/17 Jens Axel Søgaard :
> At this point I ran out of steam.
Success! I have now managed to build libcairo from scratch.
By luck I fell over:
http://cairographics.org/end_to_end_build_for_mac_os_x/
which I was able to follow without too many problems.
A few notes, white I can remember th
If I were making something like case-lambda/contract, which would be
better/make more sense?
#lang racket
(require test-engine/racket-tests)
;; this one takes a contract within each case, and puts in in a case->
for you:
(define-syntax-rule (case-lambda/contract-1 [args c e0 e ...] ...)
Why does the following code generate visual artefacts along the right and
bottom
edges of the image? How do I eliminate it?
#lang racket
(require 2htdp/image)
(define (crop-to-aspect-ratio im final-width final-height)
(let* ([W (image-width im)]
[H (image-height im)]
[wh-rati
I'm not seeing what you're seeing, I think. Can you send a screenshot (or a
pointer to it)?
Robby
On Mon, Nov 18, 2013 at 5:59 PM, Daniel Prager wrote:
> Why does the following code generate visual artefacts along the right and
> bottom
> edges of the image? How do I eliminate it?
>
> #lang ra
Image attached.
System: Mac, OS X 10.8.5, Racket 5.3.6.
Dan
On Tue, Nov 19, 2013 at 11:28 AM, Robby Findler wrote:
> I'm not seeing what you're seeing, I think. Can you send a screenshot (or
> a pointer to it)?
>
> Robby
>
>
> On Mon, Nov 18, 2013 at 5:59 PM, Daniel Prager
> wrote:
>
>> Why
Ah. I'm not sure which change affected this, but in the git version from
last night I see a solid red square (and I do see the same thing as you in
5.3.6).
Robby
On Mon, Nov 18, 2013 at 6:36 PM, Daniel Prager wrote:
> Image attached.
>
> System: Mac, OS X 10.8.5, Racket 5.3.6.
>
> Dan
>
>
> On
Thanks for checking it out -- sounds like it may be fixed / one for the
test suite.
Will 5.3.7 be coming soon?
Dan
On Tue, Nov 19, 2013 at 11:40 AM, Robby Findler wrote:
> Ah. I'm not sure which change affected this, but in the git version from
> last night I see a solid red square (and I do
Version 6.0 is the next one and we're pretty late in the release cycle,
yep. You can follow along on the dev@ mailing list.
Robby
On Mon, Nov 18, 2013 at 6:45 PM, Daniel Prager wrote:
> Thanks for checking it out -- sounds like it may be fixed / one for the
> test suite.
>
> Will 5.3.7 be comin
Anyone mind if I claim the "#lang" language name "paddle"?
The use I have in mind is not important, and I'm not attached to the
name, so if anyone would like to keep the name available for some other
purpose, just let me know soon.
Neil V.
Racket Users list:
http://lis
Hi again racketers,
In doubt, I just tried on racket stable 5.3.6, same thing :
fridim@web:~$ curl -I localhost:8000 # working.rkt
HTTP/1.1 200 Okay
Date: Tue, 19 Nov 2013 03:43:57 GMT
Last-Modified: Tue, 19 Nov 2013 03:43:57 GMT
Server: Racket
Content-Type: text/html; charset=utf-8
Cache-Contr
If I want to have a PLaneT package "foo" that sets up a "#lang foo" to
refer to itself, is the following the right way to do the "raco link"?
* Have the "info.rkt" "post-install-collection" use procedure "links"
from module "setup/link", using "this-expression-source-directory" to
figure out t
On Mon, Nov 18 2013, Matthew Flatt wrote:
> * Always using `only-in` or `prefix-in` seems too painful. (We know
>that in some languages it's conventional to always prefix imports,
>but those languages don't consider things like `lambda` or the
>application form to be imports.)
Not su
35 matches
Mail list logo
