On 2013-01-13 22:02:44 -0500, Harry Spier wrote:
> Is this a bug in contracts? When I ran the following code the
> contract in onion% didn't give me an error, yet the contract is on an
> "init sh" but the class doesn't have an "init sh" it has an
> "init-field sh". See the line with the comment ;
Is this a bug in contracts? When I ran the following code the
contract in onion% didn't give me an error, yet the contract is on an
"init sh" but the class doesn't have an "init sh" it has an
"init-field sh". See the line with the comment ;THIS LINE SHOULD
USE init-field not init
Thanks,
Har
At Mon, 14 Jan 2013 01:21:46 +0100, Jens Axel Søgaard wrote:
> Hi All,
>
> I'd like to change the program below s.t. the
> local-expand uses an internal definition context.
> Simply changing 'top-level to 'module does not work.
>
> I have tried to use various combinations of
> - (generate-expan
Hi All,
I'd like to change the program below s.t. the
local-expand uses an internal definition context.
Simply changing 'top-level to 'module does not work.
I have tried to use various combinations of
- (generate-expand-context #t)
- syntax-local-make-definition-context
- syntax-local-bind-
Ok it seems `initialize-ns-app' might not be necessary after all, sorry. I
looked at the python allegro5 bindings and they run a users thunk by passing it
to al_run_main which does all the proper initialization.
;; allegro5.rkt
(define (run thunk)
(define (callback argc argv)
(thunk)
0
On Sunday, January 13, 2013, Jon Rafkind wrote:
> Does the entire application have to live within the dynamic extent of the
> `initialize-ns-app' call or just making the screen?
>
>
I have not tested this, but I think it may be sufficient to wait until the
system calls activateNow. So maybe add a
At Sun, 13 Jan 2013 13:50:52 -0700, Danny Yoo wrote:
> > You may want to use `ffi/unsafe/nsalloc'.
>
> Ok, I see now.
>
>
> As a followup: I've found that I need to have this (or require
> ffi/unsafe/nsalloc, which provides this):
>
> (define cocoa-lib (ffi-lib (format
> "/System/Library/Fr
Does the entire application have to live within the dynamic extent of the
`initialize-ns-app' call or just making the screen?
(initialize-ns-app (lambda () (create-display))
(do-rest-of-program)
or
(initialize-ns-app (lambda () (create-display) (do-rest-of-program))
On 01/13/2013 03:14 PM, Dan
Hi Jon,
[Also CCing the Racket mailing list. For folks who are writing
bindings to graphical libraries such as SDL, the following should be
relevant.]
When using the Allegro bindings on Mac OS X, the user will see an
exception on screen instantiation unless the program's running under a
Cocoa
It was a case of not seeing the forrest for the tree.
> (define-syntax (display-types stx)
> (displayln (syntax-parameter-value #'*types))
A * is missing.
Sorry for the noise,
Jens Axel
Racket Users list:
http://lists.racket-lang.org/users
Hi All,
The program below gives this error:
collects/racket/stxparam-exptime.rkt:11:4:
syntax-parameter-value: contract violation
expected: syntax-parameter?
given: #f
Why?
/Jens Axel
#lang racket
(require racket/stxparam
racket/splicing)
(define-syntax-parameter *types* 'f
> You may want to use `ffi/unsafe/nsalloc'.
Ok, I see now.
As a followup: I've found that I need to have this (or require
ffi/unsafe/nsalloc, which provides this):
(define cocoa-lib (ffi-lib (format
"/System/Library/Frameworks/Cocoa.framework/Cocoa")))
before calling into import-class with
The `ffi/unsafe/objc' library does not depend on `racket/gui/base'.
But `racket/gui/base' initializes `NS...' libraries in various ways. In
particular, it causes the "Foundation" framework to be loaded, which is
needed for `(import-class NSAutoreleasePool)'.
You may want to use `ffi/unsafe/nsallo
I'm playing with the Objective C bindings, and I'm encountering a
behavior that I don't understand yet. Given the following program:
;;;
#lang racket/base
(require ffi/unsafe/objc
ffi/unsafe)
(import-class NSAutoreleasePool)
(define pool (tell (tell NSAutoreleaseP
Thanks Matthias. BTW I find changing the Java examples to Racket very
instructive and makes me appreciate the clarity of Racket.
Cheers,
Harry
On Sun, Jan 13, 2013 at 12:14 PM, Matthias Felleisen
wrote:
>
> Not yet. We are in the process of adding a gradual type system that deals
> with our cl
> I was wondering about current status of Moby. Is it still active? How
> stable? What is and is not yet supported?
Moby is deprecated in favor of its successor, Whalesong.
http://hashcollision.org/whalesong/
Moby unfortunately didn't provide the performance I needed for
applications, so
Not yet. We are in the process of adding a gradual type system that deals with
our classes, but we're not beyond the paper design phase. You can do one of two
things:
(1) use define/contract for the classes and formulate the types as contracts.
You don't get compile-time checking but run-time
I think you want to use a new definition of pseudo-parameter/c that uses
blame objects -- the code you quote is using old APIs in general. Check out
section 7.7 in the Reference.
But you might also just be able to avoid pseudo-parameters entirely,
depending on how you're using them.
Robby
On S
On Sun, Jan 13, 2013 at 9:14 AM, Răzvan Rotaru wrote:
> In my case the problem is I don't get any reply from the package owner (Dave
> Herman). Maybe the email address is not valid anymore.
I know that email address still works for Dave, but he's very busy and
not an active Racket programmer any
Thanks,
I have found out that you can apply your patches to the cache
(~/.racket/planet/300/5.2.1/cache/) and it works. This way you can at least
apply the fixes on your local machine. I don't know if and when the cache
files are refreshed with the version from planet (therefore overwriting my
pat
20 matches
Mail list logo
