[racket-users] [docs suggest] Suggested documentation change for Structure Inspectors

[David Storrs]

Preface:

There have been a number of times that I've seen something in the
documentation that I would like to suggest an improvement to -- the
occasional typo, an idea for a clarifying example, etc.
Unfortunately, finding specific parts of the documentation in git
feels extremely difficult.  There are several different racket
repositories on Github and the documentation sprawls across many
.scrbl fragments instead of being gathered in whole pages that map to
the URLs on the website.  Perhaps if I spent a few hours poring over
it I could figure out the underlying pattern and then everything would
be obvious, but I'm afraid I lack the energy.  If someone wants to put
together an easy-to-follow tutorial on how to submit documentation
changes, I'd love to read it.

Until then, submitting pull requests against the documentation is
simply too high a bar for me.  Still, I would like to be helpful to
the community, so I've got one here in text form.  I'm not sure if
this is welcome or if there's a specific person to submit to or etc --
please let me know and I either won't submit more or won't send them
to the list.


SUGGESTION:
Here is a suggested bit of documentation to be appended to the
'struct-info' section of the docs at
https://docs.racket-lang.org/reference/inspectors.html?q=struct-info#%28def._%28%28quote._~23~25kernel%29._struct-info%29%29

-START
Note that structs are placed under the control of the @italic{parent}
of the inspector provided at their definition site, or the parent of
the default inspector if one was not provided.   As a result,
struct-info is unlikely to return useful information unless you or
your environment have changed the current-inspector value at some
point. See @secref["inspectors" #:doc '(lib
"scribblings/reference/reference.scrbl")] for more detail.
--END


And here is a suggested bit of documentation for
https://docs.racket-lang.org/reference/inspectors.html.  This is a
lightly edited version of the explanation that Jack Firth gave me in a
separate thread, with an additional bit derived from code that
Matthias provided. I recommend replacing the second paragraph with the
following:

-START
When a structure type is created, an inspector can be supplied. The
given inspector is @bold{not} the one that will control the new
structure type; instead, the given inspector’s @bold{parent} will
control the type. This prevents modules from reflecting or modifying
structs defined by other modules.

The reason for this is that a module that defines an opaque struct
type (that is, one that is not transparent or prefab) is expected to
be responsible for exporting to other modules all the functions that
are necessary for using that type. Anything not explicitly exported by
the module is not allowed, even through reflective operations like
struct-info. The exception to this rule is when some entity above the
modules is controlling them all, such as a debugger, an IDE, or a
server running client-supplied code. In these cases, the controlling
code has the option to make a child inspector and run all the modules
under that child inspector, giving the controlling code access to all
struct types through the parent inspector. This kind of setup can be
nested to arbitrary depth.

The effect of the above is that in most cases you will not be able to
reflect a structure by way of struct-info etc.

Finally, note that the constructor for a type has the same name as the
transformer binding for that type.  Therefore, there is a pitfall with
this code:

@racketblock{
(struct person (name age))
(provide person)
}

It exports both the constructor and the transformer binding, thereby
making it possible for another module to reflect your struct and
potentially violate its invariants.  In order to prevent this, set a
contract on the export:

@racketblock{
(struct person (name age))
(provide (contract-out (person (-> string natural-number/c person?
}

--END

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] struct-info

[David Storrs]

Thanks Matthias, that makes sense.

On Tue, Feb 12, 2019 at 8:50 PM Matthias Felleisen
 wrote:
>
>
>
> > On Feb 12, 2019, at 5:28 PM, David Storrs  wrote:
> >
> > On Tue, Feb 12, 2019 at 5:03 PM  wrote:
> 
>  This is nice for defining abstract types, but it can be pretty 
>  inconvenient for defining plain old aggregated data types that just have 
>  a bundle of fields. When defining those types as structs, consider using 
>  the #:transparent option. This means "use no inspector at all" (roughly) 
>  and lets `struct-info` Just Work (TM) without any inspector wrangling. 
>  The downside is that other modules may be able to break your type's 
>  invariants and possibly circumvent your contracts.
> >>>
> >>>
> >>> That's what I expected, but it doesn't seem to work:
> >>>
>  (struct person (name age) #:transparent)
>  (struct-info person)
> >>> #f
> >>> #t
> >>>
> >>> What am I missing?
> >>
> >>
> >> I was stumped on this for a while, but then realized the problem:
> >>
> >>> (struct-info person)
> >> #f
> >> #t
> >>> (struct-info (person "Alyssa P. Hacker" 42))
> >> #
> >> #f
> >
> > Ah, I see.  Thanks, I wouldn't have guessed that an instance of a
> > struct satisfied `struct-type?`
> >
> > On the other hand, it seems relatively easy to break these
> > protections.  Is there a way to prevent that?
> >
> > ; file test1.rkt
> > #lang racket
> > (struct person (name age))
> > (provide person)
>
>
>
> The line above exports two pieces: the constructor and compile-time 
> information about the structure, including the functions as you saw. If you 
> want to protect your invariants, you replace this provide with something like
>
>(provide (contract-out (person (-> string natural-number/c person?
>
> See end for a simpler way to test such things.
>
>
>
> > ;; end of test1.rkt
> >
> >
> > ; file test2.rkt
> > #lang racket
> >
> > (require "test1.rkt"
> > (for-syntax racket
> > syntax/parse
> > syntax/parse/experimental/template
> > syntax/parse/class/struct-id))
> >
> > (define p (person 'bob 19))
> > (displayln "required ctor only of a struct defined in another file.
> > Can create, is opaque:")
> > p
> > (displayln "struct-info returns (values #f #t) since the struct isn't
> > inspectable here:")
> > (struct-info p)
> > (define-syntax struct-funcs (syntax-parser [(_ s:struct-id) (template
> > (list s.constructor-id s.accessor-id ...))]))
> > (define lst (struct-funcs person))
> > (displayln "show list of constructor and accessors that we retrieved
> > via macro:")
> > lst
> > (displayln "Fetch name ('bob) by way of accessor returned through macro:")
> > ((second lst) p)
> > ; Uncommenting the following will cause compilation to fail, since
> > person-name was not exported
> > ;(person-name p)
> > ;;  end of test2.rkt
> >
> >
> > ;; command line:
> > $ racket test2.rkt
> > required ctor only of a struct defined in another file. Can create, is 
> > opaque:
> > #
> > struct-info returns (values #f #t) since the struct isn't inspectable here:
> > #f
> > #t
> > show list of constructor and accessors that we retrieved via macro:
> > '(# # #)
> > Fetch name ('bob) by way of accessor returned through macro:
> > 'bob
> >
> > -
>
>
>
>
> #lang racket
>
> (module test1 racket
>   (provide (contract-out (person (-> string natural-number/c person?
>   (struct person (name age)))
>
> (module test2 racket
>   (require (submod ".." test1)
>(for-syntax racket
>syntax/parse
>syntax/parse/experimental/template
>syntax/parse/class/struct-id))
>
>   (define p (person 'bob 19))
>   (displayln "required ctor only of a struct defined in another file. Can 
> create, is opaque:")
>   p
>
>   (displayln "struct-info returns (values #f #t) since the struct isn't 
> inspectable here:")
>   (struct-info p)
>
>   (define-syntax struct-funcs (syntax-parser [(_ s:struct-id) (template (list 
> s.constructor-id s.accessor-id ...))]))
>   (define lst (struct-funcs person))
>   (displayln "show list of constructor and accessors that we retrieved via 
> macro:")
>   lst
>
>   (displayln "Fetch name ('bob) by way of accessor returned through macro:")
>   ((second lst) p)
>
>   ; Uncommenting the following will cause compilation to fail, since
>   ; person-name
>   )
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] struct-info

[Matthias Felleisen]

> On Feb 12, 2019, at 5:28 PM, David Storrs  wrote:
> 
> On Tue, Feb 12, 2019 at 5:03 PM  wrote:
 
 This is nice for defining abstract types, but it can be pretty 
 inconvenient for defining plain old aggregated data types that just have a 
 bundle of fields. When defining those types as structs, consider using the 
 #:transparent option. This means "use no inspector at all" (roughly) and 
 lets `struct-info` Just Work (TM) without any inspector wrangling. The 
 downside is that other modules may be able to break your type's invariants 
 and possibly circumvent your contracts.
>>> 
>>> 
>>> That's what I expected, but it doesn't seem to work:
>>> 
 (struct person (name age) #:transparent)
 (struct-info person)
>>> #f
>>> #t
>>> 
>>> What am I missing?
>> 
>> 
>> I was stumped on this for a while, but then realized the problem:
>> 
>>> (struct-info person)
>> #f
>> #t
>>> (struct-info (person "Alyssa P. Hacker" 42))
>> #
>> #f
> 
> Ah, I see.  Thanks, I wouldn't have guessed that an instance of a
> struct satisfied `struct-type?`
> 
> On the other hand, it seems relatively easy to break these
> protections.  Is there a way to prevent that?
> 
> ; file test1.rkt
> #lang racket
> (struct person (name age))
> (provide person)



The line above exports two pieces: the constructor and compile-time information 
about the structure, including the functions as you saw. If you want to protect 
your invariants, you replace this provide with something like 

   (provide (contract-out (person (-> string natural-number/c person?

See end for a simpler way to test such things. 



> ;; end of test1.rkt
> 
> 
> ; file test2.rkt
> #lang racket
> 
> (require "test1.rkt"
> (for-syntax racket
> syntax/parse
> syntax/parse/experimental/template
> syntax/parse/class/struct-id))
> 
> (define p (person 'bob 19))
> (displayln "required ctor only of a struct defined in another file.
> Can create, is opaque:")
> p
> (displayln "struct-info returns (values #f #t) since the struct isn't
> inspectable here:")
> (struct-info p)
> (define-syntax struct-funcs (syntax-parser [(_ s:struct-id) (template
> (list s.constructor-id s.accessor-id ...))]))
> (define lst (struct-funcs person))
> (displayln "show list of constructor and accessors that we retrieved
> via macro:")
> lst
> (displayln "Fetch name ('bob) by way of accessor returned through macro:")
> ((second lst) p)
> ; Uncommenting the following will cause compilation to fail, since
> person-name was not exported
> ;(person-name p)
> ;;  end of test2.rkt
> 
> 
> ;; command line:
> $ racket test2.rkt
> required ctor only of a struct defined in another file. Can create, is opaque:
> #
> struct-info returns (values #f #t) since the struct isn't inspectable here:
> #f
> #t
> show list of constructor and accessors that we retrieved via macro:
> '(# # #)
> Fetch name ('bob) by way of accessor returned through macro:
> 'bob
> 
> -




#lang racket

(module test1 racket
  (provide (contract-out (person (-> string natural-number/c person?
  (struct person (name age)))

(module test2 racket 
  (require (submod ".." test1)
   (for-syntax racket
   syntax/parse
   syntax/parse/experimental/template
   syntax/parse/class/struct-id))

  (define p (person 'bob 19))
  (displayln "required ctor only of a struct defined in another file. Can 
create, is opaque:")
  p
  
  (displayln "struct-info returns (values #f #t) since the struct isn't 
inspectable here:")
  (struct-info p)

  (define-syntax struct-funcs (syntax-parser [(_ s:struct-id) (template (list 
s.constructor-id s.accessor-id ...))]))
  (define lst (struct-funcs person))
  (displayln "show list of constructor and accessors that we retrieved via 
macro:")
  lst
  
  (displayln "Fetch name ('bob) by way of accessor returned through macro:")
  ((second lst) p)

  ; Uncommenting the following will cause compilation to fail, since
  ; person-name
  )

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Problems with syntax coloring a #lang

[Chris GauthierDickey]

Hi!

I seem to have some weird behavior with syntax coloring a #lang. Sometimes
it seems to think particular words that are normally correctly colored are
errors.

For example, if I'm starting to type a keyword, it's coloring it red (which
it should), but when I complete the word, it doesn't re-color it the right
color. Or if I intentionally delete a character and put it back in the
middle of a properly colored section, some of the letters switch to the
wrong color and don't switch back.

If I tell racket to reload the #lang extensions, it goes and colors the
buffer properly.

I know that's not much to go on, but being that it's dynamically loaded by
DrRacket, I'm having some problems debugging it!

Thanks!
Chris

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Loading foreign libraries on Windows

[Alex Harsanyi]

The only thing I can suggest than is to try to debug the problem.

I would first try to use procmon from the sysinternals suite to determine 
what API calls are made when the library is loaded into Racket, which one 
returns an error and what are the parameters to that call.  I would also 
use dependency walker to determine what other DLLs are used by libgit -- 
sometimes a DLL fails to load because some other DLL it depends on is 
missing or corrupted, but when that is the case, the error messages are 
very confusing.

Alex.

On Tuesday, February 12, 2019 at 11:11:10 PM UTC+8, Philip McGrath wrote:
>
> As far as I can tell, yes. I've confirmed that the install script is 
> getting Racket from 
> https://mirror.racket-lang.org/installers/7.2/racket-7.2-x86_64-win32.exe
>
> -Philip
>
>
> On Tue, Feb 12, 2019 at 2:01 AM Alex Harsanyi  > wrote:
>
>> Do you have x64 Racket installed? This is an error that usually comes up 
>> when a 32 bit application tries to load a 64 bit DLL.
>>
>> Alex.
>>
>> On Tuesday, February 12, 2019 at 2:18:55 PM UTC+8, Philip McGrath wrote:
>>>
>>> I'm encountering an issue using `ffi-lib` to load a DLL on Windows. The 
>>> problem appears to be specific to Racket, as I seem to be able to load the 
>>> same DLL from Python.
>>>
>>> Specifically, I'm trying to build platform-specific packages for 
>>> libgit2. I can build the library and run its test suite successfully, but 
>>> when I try to load the DLL with `ffi-lib`, using an absolute path to avoid 
>>> any search issues, it fails with the message "%1 is not a valid Win32 
>>> application.; errid=193". The AppVeyor build log is here 
>>> ,
>>>  
>>> and this is the Racket script 
>>> 
>>>  
>>> that fails to load the DLL. As I mentioned, I can load the DLL successfully 
>>> with this Python script 
>>> 
>>> .
>>>
>>> I'm not much of a Windows person, and I'm not sure what else to do to 
>>> debug this.
>>>
>>> -Philip
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to racket-users...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] struct-info

[David Storrs]

On Tue, Feb 12, 2019 at 5:03 PM  wrote:
>>>
>>> This is nice for defining abstract types, but it can be pretty inconvenient 
>>> for defining plain old aggregated data types that just have a bundle of 
>>> fields. When defining those types as structs, consider using the 
>>> #:transparent option. This means "use no inspector at all" (roughly) and 
>>> lets `struct-info` Just Work (TM) without any inspector wrangling. The 
>>> downside is that other modules may be able to break your type's invariants 
>>> and possibly circumvent your contracts.
>>
>>
>> That's what I expected, but it doesn't seem to work:
>>
>> > (struct person (name age) #:transparent)
>> > (struct-info person)
>> #f
>> #t
>>
>> What am I missing?
>
>
> I was stumped on this for a while, but then realized the problem:
>
> > (struct-info person)
> #f
> #t
> > (struct-info (person "Alyssa P. Hacker" 42))
> #
> #f

Ah, I see.  Thanks, I wouldn't have guessed that an instance of a
struct satisfied `struct-type?`

On the other hand, it seems relatively easy to break these
protections.  Is there a way to prevent that?

; file test1.rkt
#lang racket
(struct person (name age))
(provide person)
;; end of test1.rkt


; file test2.rkt
#lang racket

(require "test1.rkt"
 (for-syntax racket
 syntax/parse
 syntax/parse/experimental/template
 syntax/parse/class/struct-id))

(define p (person 'bob 19))
(displayln "required ctor only of a struct defined in another file.
Can create, is opaque:")
p
(displayln "struct-info returns (values #f #t) since the struct isn't
inspectable here:")
(struct-info p)
(define-syntax struct-funcs (syntax-parser [(_ s:struct-id) (template
(list s.constructor-id s.accessor-id ...))]))
(define lst (struct-funcs person))
(displayln "show list of constructor and accessors that we retrieved
via macro:")
lst
(displayln "Fetch name ('bob) by way of accessor returned through macro:")
((second lst) p)
; Uncommenting the following will cause compilation to fail, since
person-name was not exported
;(person-name p)
;;  end of test2.rkt


;; command line:
$ racket test2.rkt
required ctor only of a struct defined in another file. Can create, is opaque:
#
struct-info returns (values #f #t) since the struct isn't inspectable here:
#f
#t
show list of constructor and accessors that we retrieved via macro:
'(# # #)
Fetch name ('bob) by way of accessor returned through macro:
'bob

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] struct-info

[Shu-Hung You]

On Tue, Feb 12, 2019 at 3:55 PM David Storrs  wrote:
>
> On Tue, Feb 12, 2019 at 4:46 PM  wrote:
> >>
> >> Thank you for the explanation.  Can I ask why the heck it works this
> >> way?  This seems to be explicitly designed for maximal surprise and
> >> minimal usefulness.
> >
> >
> > It works that way so that, by default, modules can't inspect, modify, or 
> > otherwise muck around with structs defined by other modules. Opaque structs 
> > (that is, structs that aren't transparent and aren't prefab) aren't really 
> > meant to be used like "plain old data objects" with fields and accessors, 
> > they're more like building blocks for abstract data types. A module that 
> > defines an opaque struct type is expected to be responsible for exporting 
> > to other modules all the functions that are necessary for using that type. 
> > Anything not explicitly exported by the module is not allowed, even through 
> > reflective operations like struct-info. The exception to this rule is when 
> > some entity above the modules is controlling them all, such as a debugger, 
> > an IDE, or a server running client-supplied code. In these cases, the 
> > controlling code has the option to make a child inspector and run all the 
> > modules under that child inspector, giving the controlling code access to 
> > all struct types through the parent inspector. This kind of setup can be 
> > nested arbitrarily deep.
>
> I see.  That makes sense.  I think it would be worth expanding the
> documentation on that; I'm happy to provide a suggestion later
> tonight, but I will need to do it through email instead of via pull
> request.  I have long since given up on being able to find anything in
> the Racket github in order to provide patches.  It's simply too
> unintuitive and time-intensive to find the relevant section in
> multiple repositories where the documentation is in randomly-named
> fragments scattered across multiple directories instead of being
> individual files with guessable names.
>
>
> >
> > This is nice for defining abstract types, but it can be pretty inconvenient 
> > for defining plain old aggregated data types that just have a bundle of 
> > fields. When defining those types as structs, consider using the 
> > #:transparent option. This means "use no inspector at all" (roughly) and 
> > lets `struct-info` Just Work (TM) without any inspector wrangling. The 
> > downside is that other modules may be able to break your type's invariants 
> > and possibly circumvent your contracts.
>
> That's what I expected, but it doesn't seem to work:
>
> > (struct person (name age) #:transparent)
> > (struct-info person)
> #f
> #t
>
> What am I missing?
>

It takes an instance of person.

(struct-info (person "Me" 3.14))

FWIW if you already have the struct type descriptor (which is what
struct-info returns), you can directly call struct-type-info.

(struct-type-info
 (let-values ([(desc skip?) (struct-info (person "Me" 3.14))])
   desc))

;; struct:person is introduced by the (struct person ...) form
(struct-type-info struct:person)

> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] struct-info

[jackhfirth]

>
> This is nice for defining abstract types, but it can be pretty 
>> inconvenient for defining plain old aggregated data types that just have a 
>> bundle of fields. When defining those types as structs, consider using the 
>> #:transparent option. This means "use no inspector at all" (roughly) and 
>> lets `struct-info` Just Work (TM) without any inspector wrangling. The 
>> downside is that other modules may be able to break your type's invariants 
>> and possibly circumvent your contracts. 
>
>
> That's what I expected, but it doesn't seem to work: 
>
> > (struct person (name age) #:transparent) 
> > (struct-info person) 
> #f 
> #t 
>
> What am I missing?
>

I was stumped on this for a while, but then realized the problem:

> (struct-info person)
#f
#t
> (struct-info (person "Alyssa P. Hacker" 42))
#
#f

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] struct-info

[David Storrs]

On Tue, Feb 12, 2019 at 4:46 PM  wrote:
>>
>> Thank you for the explanation.  Can I ask why the heck it works this
>> way?  This seems to be explicitly designed for maximal surprise and
>> minimal usefulness.
>
>
> It works that way so that, by default, modules can't inspect, modify, or 
> otherwise muck around with structs defined by other modules. Opaque structs 
> (that is, structs that aren't transparent and aren't prefab) aren't really 
> meant to be used like "plain old data objects" with fields and accessors, 
> they're more like building blocks for abstract data types. A module that 
> defines an opaque struct type is expected to be responsible for exporting to 
> other modules all the functions that are necessary for using that type. 
> Anything not explicitly exported by the module is not allowed, even through 
> reflective operations like struct-info. The exception to this rule is when 
> some entity above the modules is controlling them all, such as a debugger, an 
> IDE, or a server running client-supplied code. In these cases, the 
> controlling code has the option to make a child inspector and run all the 
> modules under that child inspector, giving the controlling code access to all 
> struct types through the parent inspector. This kind of setup can be nested 
> arbitrarily deep.

I see.  That makes sense.  I think it would be worth expanding the
documentation on that; I'm happy to provide a suggestion later
tonight, but I will need to do it through email instead of via pull
request.  I have long since given up on being able to find anything in
the Racket github in order to provide patches.  It's simply too
unintuitive and time-intensive to find the relevant section in
multiple repositories where the documentation is in randomly-named
fragments scattered across multiple directories instead of being
individual files with guessable names.


>
> This is nice for defining abstract types, but it can be pretty inconvenient 
> for defining plain old aggregated data types that just have a bundle of 
> fields. When defining those types as structs, consider using the 
> #:transparent option. This means "use no inspector at all" (roughly) and lets 
> `struct-info` Just Work (TM) without any inspector wrangling. The downside is 
> that other modules may be able to break your type's invariants and possibly 
> circumvent your contracts.

That's what I expected, but it doesn't seem to work:

> (struct person (name age) #:transparent)
> (struct-info person)
#f
#t

What am I missing?

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] struct-info

[jackhfirth]

>
> Thank you for the explanation.  Can I ask why the heck it works this 
> way?  This seems to be explicitly designed for maximal surprise and 
> minimal usefulness. 
>

It works that way so that, by default, modules can't inspect, modify, or 
otherwise muck around with structs defined by other modules. Opaque structs 
(that is, structs that aren't transparent and aren't prefab) aren't really 
meant to be used like "plain old data objects" with fields and accessors, 
they're more like building blocks for abstract data types. A module that 
defines an opaque struct type is expected to be responsible for exporting 
to other modules all the functions that are necessary for using that type. 
Anything not explicitly exported by the module is not allowed, even through 
reflective operations like struct-info. The exception to this rule is when 
some entity *above* the modules is controlling them all, such as a 
debugger, an IDE, or a server running client-supplied code. In these cases, 
the controlling code has the option to make a child inspector and run all 
the modules under that child inspector, giving the controlling code access 
to all struct types through the parent inspector. This kind of setup can be 
nested arbitrarily deep.

This is nice for defining abstract types, but it can be pretty inconvenient 
for defining plain old aggregated data types that just have a bundle of 
fields. When defining those types as structs, consider using the 
#:transparent option. This means "use no inspector at all" (roughly) and 
lets `struct-info` Just Work (TM) without any inspector wrangling. The 
downside is that other modules may be able to break your type's invariants 
and possibly circumvent your contracts.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Wishlist for regexen: x mode, named captures, embeddable regexn

[David Storrs]

Good point; I should have said "built-in".

On Tue, Feb 12, 2019 at 12:54 PM Matthias Felleisen
 wrote:
>
>
>
> > On Feb 12, 2019, at 12:48 PM, David Storrs  wrote:
> >
> > That's impressive and yes, you're right that it works.  The problem is
> > that it is something non-standard, a user extension that the
> > programmer needs to know about, ensure is installed, and require.
> > Perl, Python, and the pcre library all consider named captures to be
> > first-class features of the language.  Perl considers regex
> > composition to be first-class, and Python and pcre probably do as well
> > although I haven't checked.  If you end up doing a lot of text
> > handling then these features are invaluable, so why is Racket behind
> > the times?
>
>
> Off topic.
>
> The “first class” idea caught my eye because it is always used in
> such a wrong way. In the olden days (like 10 years ago), first class
> meant that plain programs can use a value in all kinds of ways. Turning
> a set of values into first-class citizens empowers programmers.
>
> If Perl/Python and cohorts truly cared about first class support
> for such features, they would also enable plain old (and young)
> programmers to create such variants on their own. Who knows
> what else that would enable?
>
> The issue of finding and installing the correct library is a distraction
> from true power in programming languages.
>
> Tne End.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Wishlist for regexen: x mode, named captures, embeddable regexn

[Thomas F. Burdick]

On February 12, 2019 6:48:49 PM GMT+01:00, David Storrs 
 wrote:
>Actually, that raises a question:  Does Racket use the pcre library or
>does it reinvent the wheel?  If it uses pcre then why not make all the
>features available?

My goodness. Perl isn't the One True Way of regular expressions, nor is pcre 
even the canonical Perl-style regexp implementation.

That said, if you've invested a lot of effort in learning the corners of Perl 
re, I can understand wanting to have a compatible system available. It's 
powerful and well known. The good news is that one of if not the best 
implementation of Perl-style re exists in Lisp, in cl-ppcre. It was at one 
point the fastest by a factor of 2. These days I think Perl and pcre have 
improved their performance to basically catch up.

Porting it to Racket wouldn't be especially difficult. Anyone with an interest 
in Racket and an attachment to Perl-style regexp should just do it. And update 
its interface. Racket should have an even more convenient integration than CL 
(library but why not also a lang).

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Loading foreign libraries on Windows

[George Neuner]

On 2/12/2019 11:44 AM, Jens Axel Søgaard wrote:

FWIW here is the readme describing how to build libraries for Windows:

https://github.com/racket/racket/tree/master/racket/src/native-libs


That is a guide useful in general, but it doesn't answer my question to 
Philip.  Plain C DLLs are (for the most part) build-chain agnostic, but 
non-C DLLs can provide C callable functions, and Visual Studio can 
create some types of non-C DLLs that GCC can't.


20 years hence, Microsoft's C compiler isn't even fully C90 compliant.  
They've stated publicly that full C90 compliance will not be achieved 
and C99 and later won't be addressed except for features specifically 
needed by "major customers".


They seem to care much more about C++ compliance than C.  They are 
(AFAIK) fully compliant with C++03.  They aren't fully compliant with 
C++11 or later, but they are much closer to compliance with the C++ 
standards than they are with C.


George

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Wishlist for regexen: x mode, named captures, embeddable regexn

[Matthias Felleisen]

> On Feb 12, 2019, at 12:48 PM, David Storrs  wrote:
> 
> That's impressive and yes, you're right that it works.  The problem is
> that it is something non-standard, a user extension that the
> programmer needs to know about, ensure is installed, and require.
> Perl, Python, and the pcre library all consider named captures to be
> first-class features of the language.  Perl considers regex
> composition to be first-class, and Python and pcre probably do as well
> although I haven't checked.  If you end up doing a lot of text
> handling then these features are invaluable, so why is Racket behind
> the times?


Off topic. 

The “first class” idea caught my eye because it is always used in 
such a wrong way. In the olden days (like 10 years ago), first class
meant that plain programs can use a value in all kinds of ways. Turning
a set of values into first-class citizens empowers programmers. 

If Perl/Python and cohorts truly cared about first class support 
for such features, they would also enable plain old (and young) 
programmers to create such variants on their own. Who knows 
what else that would enable? 

The issue of finding and installing the correct library is a distraction
from true power in programming languages. 

Tne End. 


-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Wishlist for regexen: x mode, named captures, embeddable regexn

[David Storrs]

On Mon, Feb 11, 2019 at 7:08 PM Philip McGrath  wrote:
>
> On Mon, Feb 11, 2019 at 2:32 PM David Storrs  wrote:
>>
>> It would be great if Perl's / pcre's "x" mode could be pulled into
>> Racket, ideally with modifiers on the end of the regexp instead of
>> inside it.  This mode specifies that all whitespace in the pattern
>> should be ignored, so if you want to actually match whitespace then
>> you need to specify it.  Example:
>>
>> ; tokenizer code running under the at-exp sublanguage: match a word
>> boundary, 'var', whitespace, one or more contiguous word characters
>> (ASCII alphanumerics or _), and then another word boundary
>>
>> @pregexp{\b var \s+ \w+ \b}x
>
>
> Would this do what you want?
>
> #lang at-exp racket
>
> (define (pregexp-x . args)
>   (pregexp
>(regexp-replace* #px"\\s+" (string-append* args) "")))
>
> @pregexp-x{\b var \s+ \w+ \b} ;; -> #px"\\bvar\\s+\\w+\\b"
>
> (With an easy optimization being to make `pregexp-x` a macro so that it can 
> do that work at compile-time when all of the args are string literals.)
>

It would, yes.  Thanks.  Although, see below.

>> Oh, and if I'm already asking for the moon, does Racket have any
>> equivalent to Perl's named captures or composable regexen, or any
>> possibility of adding them?
>>
>> (regexp-match @px{\b(?hi|hello)} "hi bob")
>> (println greet) ; prints "hi"
>>
>
> I think both of these could be implemented well in "user space."
>  [code]

That's impressive and yes, you're right that it works.  The problem is
that it is something non-standard, a user extension that the
programmer needs to know about, ensure is installed, and require.
Perl, Python, and the pcre library all consider named captures to be
first-class features of the language.  Perl considers regex
composition to be first-class, and Python and pcre probably do as well
although I haven't checked.  If you end up doing a lot of text
handling then these features are invaluable, so why is Racket behind
the times?

Actually, that raises a question:  Does Racket use the pcre library or
does it reinvent the wheel?  If it uses pcre then why not make all the
features available?

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Python's append vs Racket's append and helping novices understand the implications

[Matthias Felleisen]

This is perfect! Thanks — Matthias




> On Feb 11, 2019, at 11:04 PM, Claes Wallin (韋嘉誠)  wrote:
> 
> For anyone creating such a web page for Python to Racket specifically,
> there is probably a great deal of inspiration, and reminders of
> stumbling blocks, to be found in Arne Babenhauserheide's
> https://www.draketo.de/py2guile book (available online for free) about
> going from Python to Guile Scheme.
> 
> -- 
>   /c
> 
> On Sun, Feb 3, 2019 at 7:00 AM Matthias Felleisen
>  wrote:
>> Racket needs *you*. Please.
>> 
>> The proper approach is to have short pages for different language 
>> immigration groups: Python and R come to mind as obvious examples but I am 
>> sure there are others.
>> 
>> What I mean is we need help and *you* can help. Let me explain it with the 
>> Python example:
>> 
>> 1. Set up a page (wiki?) called “From Python to Racket”
>> 
>> 2. Create two sections that are immediately visible from the top:
>> 
>>— idioms
>>— performance pitfalls
>> 
>> 3. In the specific case of Python, the second subsection needs to start with 
>> a subsection on
>> 
>>— Python Lists aren’t Racket Lists
>>— then point to data/ralis and show how to transliterate the 
>> loop/append example like this
>>— optionally also show the more native Racket idiom
>> 
>> 4. When anyone observers another blog/social media/whatever post on Racket 
>> is slow because I come from Python,
>> 
>>(a) point the posters to the page  or
>>(b) if it is a new case, write a section for this example then do (a)
>> 
>> 
>> If you want to help advertise Racket to others, this is an excellent way of 
>> helping out.
>> 
>> Thanks — Matthias
>> 
>> [[ p.s. For my very first Python program (a couple of days before meeting 
>> with GvR), I used Python’s append and was annoyed beyond belief. ]]
>> 
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] struct-info

[David Storrs]

On Tue, Feb 12, 2019 at 11:43 AM Shu-Hung You
 wrote:
>
> On Tue, Feb 12, 2019 at 10:04 AM David Storrs  wrote:
> >
> > Could someone point me to the FM on how to properly use struct-info?
> > For the life of me, I cannot get anything except (values #f #t) out of
> > it.  I see that:
> >
> > 1) struct-info only works with struct types that are under the control
> > of the current inspector.
> >
> > 2) You can provide an inspector to a struct declaration, but it will
> > be placed under the control of the **parent** of what you passed it,
> > not the actual thing you passed it.  This breaks my brain.
> >
>
> The inspector used at struct type creation time needs to be controlled
> by the current inspector so you can obtain reflective information.
> That is, the inspector used at struct type creation time is a
> sub(-sub-sub-...) inspector of the current inspector.
>
> #lang racket/base
>
> (require racket/struct-info)
>
> (define old-insp (current-inspector))
> (define insp (make-inspector))
>
> (current-inspector insp)
> (struct S (field1 field2))
> (current-inspector old-insp)
>
> (define s
>   (S 5 'hi))
>
> (struct-info s) ;;=> ok
>
> (current-inspector insp)
> (struct-info s) ;;=> #f #t

Thank you for the explanation.  Can I ask why the heck it works this
way?  This seems to be explicitly designed for maximal surprise and
minimal usefulness.


>
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to racket-users+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Loading foreign libraries on Windows

[Jens Axel Søgaard]

FWIW here is the readme describing how to build libraries for Windows:

https://github.com/racket/racket/tree/master/racket/src/native-libs

Den tir. 12. feb. 2019 kl. 17.37 skrev George Neuner :

> Hi Philip,
>
> On 2/12/2019 1:18 AM, Philip McGrath wrote:
>
> I'm encountering an issue using `ffi-lib` to load a DLL on Windows. The
> problem appears to be specific to Racket, as I seem to be able to load the
> same DLL from Python.
>
> Specifically, I'm trying to build platform-specific packages for libgit2.
> I can build the library and run its test suite successfully, but when I try
> to load the DLL with `ffi-lib`, using an absolute path to avoid any search
> issues, it fails with the message "%1 is not a valid Win32 application.;
> errid=193". The AppVeyor build log is here
> ,
> and this is the Racket script
> 
> that fails to load the DLL. As I mentioned, I can load the DLL successfully
> with this Python script
> 
> .
>
> I'm not much of a Windows person, and I'm not sure what else to do to
> debug this.
>
>
> If it isn't a simple 32-bit/64-bit mismatch, then it could be a lot of
> things.  :-(
>
> Unlike *nix, Windows supports several different kinds of DLLs.  If the
> wrong setting are used to compile or link, a Windows DLL can behave very
> oddly ... including working in one context (Python), but not in another
> (Racket).
>
> You say you built the library from source?   I briefly looked at the
> source, but I'm not very familiar with cmake, and I don't see where the
> compile and link options are being defined.  Which compiler did you use and
> with what settings?
> [If they are defined in the project somewhere, you can just point me to
> the file(s).]
>
> George
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
-- 
Jens Axel Søgaard

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] struct-info

[Shu-Hung You]

On Tue, Feb 12, 2019 at 10:04 AM David Storrs  wrote:
>
> Could someone point me to the FM on how to properly use struct-info?
> For the life of me, I cannot get anything except (values #f #t) out of
> it.  I see that:
>
> 1) struct-info only works with struct types that are under the control
> of the current inspector.
>
> 2) You can provide an inspector to a struct declaration, but it will
> be placed under the control of the **parent** of what you passed it,
> not the actual thing you passed it.  This breaks my brain.
>

The inspector used at struct type creation time needs to be controlled
by the current inspector so you can obtain reflective information.
That is, the inspector used at struct type creation time is a
sub(-sub-sub-...) inspector of the current inspector.

#lang racket/base

(require racket/struct-info)

(define old-insp (current-inspector))
(define insp (make-inspector))

(current-inspector insp)
(struct S (field1 field2))
(current-inspector old-insp)

(define s
  (S 5 'hi))

(struct-info s) ;;=> ok

(current-inspector insp)
(struct-info s) ;;=> #f #t


> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Loading foreign libraries on Windows

[George Neuner]

Hi Philip,

On 2/12/2019 1:18 AM, Philip McGrath wrote:
I'm encountering an issue using `ffi-lib` to load a DLL on Windows. 
The problem appears to be specific to Racket, as I seem to be able to 
load the same DLL from Python.


Specifically, I'm trying to build platform-specific packages for 
libgit2. I can build the library and run its test suite successfully, 
but when I try to load the DLL with `ffi-lib`, using an absolute path 
to avoid any search issues, it fails with the message "%1 is not a 
valid Win32 application.; errid=193". The AppVeyor build log is here 
, 
and this is the Racket script 
 
that fails to load the DLL. As I mentioned, I can load the DLL 
successfully with this Python script 
.


I'm not much of a Windows person, and I'm not sure what else to do to 
debug this.


If it isn't a simple 32-bit/64-bit mismatch, then it could be a lot of 
things. :-(


Unlike *nix, Windows supports several different kinds of DLLs.  If the 
wrong setting are used to compile or link, a Windows DLL can behave very 
oddly ... including working in one context (Python), but not in another 
(Racket).


You say you built the library from source?   I briefly looked at the 
source, but I'm not very familiar with cmake, and I don't see where the 
compile and link options are being defined.  Which compiler did you use 
and with what settings?
[If they are defined in the project somewhere, you can just point me to 
the file(s).]


George

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] struct-info

[David Storrs]

Could someone point me to the FM on how to properly use struct-info?
For the life of me, I cannot get anything except (values #f #t) out of
it.  I see that:

1) struct-info only works with struct types that are under the control
of the current inspector.

2) You can provide an inspector to a struct declaration, but it will
be placed under the control of the **parent** of what you passed it,
not the actual thing you passed it.  This breaks my brain.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Package not updating after push?

[David Storrs]

Awesome, thanks!

On Tue, Feb 12, 2019 at 10:49 AM Jay McCarthy  wrote:
>
> There was an internal error, but it is fixed now. Thanks!
>
> On Mon, Feb 11, 2019 at 5:37 PM David Storrs  wrote:
> >
> > I've pushed some enhancements to the struct-plus-plus package but the
> > package server is not picking them up.  I've updated the version
> > number in info.rkt and I've done "Rescan all my packages" twice.  What
> > should I do?
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to racket-users+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> -=[ Jay McCarthy   http://jeapostrophe.github.io]=-
> -=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
> -=[ Moses 1:33: And worlds without number have I created; ]=-

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Package not updating after push?

[Jay McCarthy]

There was an internal error, but it is fixed now. Thanks!

On Mon, Feb 11, 2019 at 5:37 PM David Storrs  wrote:
>
> I've pushed some enhancements to the struct-plus-plus package but the
> package server is not picking them up.  I've updated the version
> number in info.rkt and I've done "Rescan all my packages" twice.  What
> should I do?
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
-=[ Jay McCarthy   http://jeapostrophe.github.io]=-
-=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
-=[ Moses 1:33: And worlds without number have I created; ]=-

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Loading foreign libraries on Windows

[Philip McGrath]

As far as I can tell, yes. I've confirmed that the install script is
getting Racket from
https://mirror.racket-lang.org/installers/7.2/racket-7.2-x86_64-win32.exe

-Philip


On Tue, Feb 12, 2019 at 2:01 AM Alex Harsanyi 
wrote:

> Do you have x64 Racket installed? This is an error that usually comes up
> when a 32 bit application tries to load a 64 bit DLL.
>
> Alex.
>
> On Tuesday, February 12, 2019 at 2:18:55 PM UTC+8, Philip McGrath wrote:
>>
>> I'm encountering an issue using `ffi-lib` to load a DLL on Windows. The
>> problem appears to be specific to Racket, as I seem to be able to load the
>> same DLL from Python.
>>
>> Specifically, I'm trying to build platform-specific packages for libgit2.
>> I can build the library and run its test suite successfully, but when I try
>> to load the DLL with `ffi-lib`, using an absolute path to avoid any search
>> issues, it fails with the message "%1 is not a valid Win32 application.;
>> errid=193". The AppVeyor build log is here
>> ,
>> and this is the Racket script
>> 
>> that fails to load the DLL. As I mentioned, I can load the DLL successfully
>> with this Python script
>> 
>> .
>>
>> I'm not much of a Windows person, and I'm not sure what else to do to
>> debug this.
>>
>> -Philip
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] 2nd Call for Participation: BOB 2019 (Mar 22, Berlin - right before Racketfest)

[Michael Sperber]

BOB 2019 makes for a great combo with Racketfest, with lots of Racket
and FP content!


   BOB 2019
  Conference
 “What happens if we simply use what’s best?”
March 22, 2019, Berlin
   http://bobkonf.de/2019/
   Program: http://bobkonf.de/2019/en/program.html
  Registration: http://bobkonf.de/2019/en/registration.html

   
BOB is the conference for developers, architects and decision-makers
to explore technologies beyond the mainstream in software development,
and to find the best tools available to software developers today. Our
goal is for all participants of BOB to return home with new insights
that enable them to improve their own software development
experiences.

The program features 14 talks and 8 tutorials on current topics:

http://bobkonf.de/2019/en/program.html

The subject range of talks includes functional programming, formal
methods, event sourcing, music, advanced SQL, logic, and feelings.

The tutorials feature introductions to Racket, Clojure, Functional
Programming, TypeScript, type-level programming, SQL indexing,
probabilistic programming, and hardware.

Gabriele Keller will give the keynote talk.

Registration is open online:

http://bobkonf.de/2019/en/registration.html

NOTE: The early-bird rates expire on February 19, 2019!

BOB cooperates with the RacketFest conference on the following day:

https://racketfest.com/

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.