[racket-users] Interning custom types?

[jackhfirth]

If I wanted to make my own interned data type, how hard would that be? I 
have a datatype representing an immutable sorted set of keywords and I want 
to guarantee that total memory use for these sets depends only on the 
number of unique combinations of keywords created by a program.

-- 
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] Error handling for the GUI

[Greg Hendershott]

Using `exn->string` from `racket/exn` should usually include context
("stack trace")?

  
https://docs.racket-lang.org/reference/exns.html#(def._((lib._racket%2Fexn..rkt)._exn-~3estring))

Also there will be more context to see, if in DrRacket or racket-mode
you've selected that higher level.


p.s. It's probably worth considering that many exceptions are
surprises about the world outside the program. File or network ports
couldn't be opened, read, written. Files didn't exist, or can't be
made not to exist. And so on. A program must deal with those, somehow.
Usually the exns will be something the user needs to see in the (G)UI,
ideally with a simplified message in their language, then the program
can hopefully resume just fine.

But -- contract violations aren't like that. They're about some code
surprising some other code. I think the only hope here is, run the
code enough (before the user ever does) to flush out the bad code
assumptions and fix them. Realistically that means having enough
automated tests, and running them frequently enough (like on every
code commit, or at least push, and you can't merge to master if tests
don't pass, etc.).

Because, there's rarely any good thing to tell the user, beyond
"internal error" + cryptic data for them to give tech support. In some
cases, the program is even in a state where it shouldn't continue
running and should exit. Taking the "do nothing" branch followed by
"do something" might be bad times for the user and their data. For
example, not saving new changes they made, is bad -- but it's not as
bad as also corrupting previously saved data.  Even when it's not that
dire, a contract violation usually means there aren't any great
choices.

I'm sorry if any of that sounds preachy!  TL;DR: Although it makes
sense for contract violations to be exn:fail:contract, but they're
really unlike most exn:fails. Contracts are more like ASSERTs in old
school C, and the traditional way to handle assertion failures is to
abend.

On Sat, Mar 23, 2019 at 4:03 PM Ben Greenman
 wrote:
>
> On 3/23/19, David Storrs  wrote:
> > Alex makes good points, but I'm curious about the original question:  Is
> > there a straightforward way to tell which function it was whose contract
> > was violated, aside from parsing the message?  Or, more generally, where a
> > specific exception came from?
>
> For blame errors, it might help to grab the blame object and ask it
> some questions.
>
> ```
>   #lang racket
>
>   (module a racket
> (provide (contract-out (f (-> symbol? symbol?
> (define (f sym)
>   (symbol->string sym)))
>   (require 'a)
>
>   (with-handlers ((exn:fail:contract:blame?
> (lambda (blame-err)
>   (define b (exn:fail:contract:blame-object blame-err))
>   (printf "bad value = ~s~n" (blame-value b)
> (f 'X))
>   ;; bad value = f
> ```
>
> Docs:
> https://docs.racket-lang.org/reference/Building_New_Contract_Combinators.html#(part._.Blame_.Objects)
>
> --
> 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] Error handling for the GUI

[Ben Greenman]

On 3/23/19, David Storrs  wrote:
> Alex makes good points, but I'm curious about the original question:  Is
> there a straightforward way to tell which function it was whose contract
> was violated, aside from parsing the message?  Or, more generally, where a
> specific exception came from?

For blame errors, it might help to grab the blame object and ask it
some questions.

```
  #lang racket

  (module a racket
(provide (contract-out (f (-> symbol? symbol?
(define (f sym)
  (symbol->string sym)))
  (require 'a)

  (with-handlers ((exn:fail:contract:blame?
(lambda (blame-err)
  (define b (exn:fail:contract:blame-object blame-err))
  (printf "bad value = ~s~n" (blame-value b)
(f 'X))
  ;; bad value = f
```

Docs:
https://docs.racket-lang.org/reference/Building_New_Contract_Combinators.html#(part._.Blame_.Objects)

-- 
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] Error handling for the GUI

[David Storrs]

Alex makes good points, but I'm curious about the original question:  Is
there a straightforward way to tell which function it was whose contract
was violated, aside from parsing the message?  Or, more generally, where a
specific exception came from?

On Fri, Mar 22, 2019 at 7:17 PM Alex Harsanyi 
wrote:

>
> On Saturday, March 23, 2019 at 5:17:22 AM UTC+8, James Platt wrote:
>>
>> Well, I might make some kind of compromise.  What I don't want to allow
>> is the possibility of the user experience being "I click on the button and
>> nothing happens."
>
>
> You can wrap each button callback with a `with-handlers` call that
> displays a message box when an exception is raised inside the callback, but
> this user interface might not be very pleasant to use.  Also this will not
> help you if your callback does something like:
>
> (when #f
>;; rest of the code here
>)
>
>
>> Next worst is to display a raw error message which the user can only
>> interpret by cutting and pasting it into a web search.
>
>
> If the user can do nothing about this error except report it back to the
> developer, you can just log this error to a file, display an "Internal
> Error" dialog box and instruct the user to add the log file to their bug
> report.
>
>
>> So yes, I could just get that far and then try and fix all the bugs
>> rather than try and handle every possible exception gracefully.
>
>
> If you have a limited amount of time available, I would suggest you spend
> a little of that time on code that displays "Internal Error" and most of
> that time in detecting and fixing these bugs.  You won't be able to fix all
> of them, but you can go a long way of making the "Internal Error" dialog
> box be a rare occurrence in your application.
>
> You should display more information to the user, only if the user can
> actually do something to fix the problem (e.g if you cannot open a file,
> tell the user which file you cannot open), otherwise your application
> should just log the exception into a file, along with other debugging
> information so you can reproduce the problem, than instruct the user to
> report a bug and attach the log file.
>
>
>>  More likely, meet somewhere in the middle of those approaches.
>>
>>
>> On Mar 22, 2019, at 4:55 PM, Robby Findler wrote:
>>
>> > I know this will sound silly, but you could just consider them bugs and
>> the fix them? (I went through a similar thought process with DrRacket years
>> ago and that was the conclusion I came to-- just slap an "internal error"
>> message on it so people aren't confused about it being a bug in their
>> program.)
>> >
>> > Robby
>> >
>> > On Fri, Mar 22, 2019 at 3:09 PM James Platt 
>> wrote:
>> > I'm working on displaying informative error messages in a GUI and I
>> have been finding that many of the things I need to handle are contract
>> violations in downstream functions.  The thing is that it seems like there
>> ought to be a better way than the methods I can think of.
>> >
>> > It's very simple to use the predicate exn:fail:contract? to tell if
>> there was a contract violation but this doesn't tell me which downstream
>> function or which parameter caused the error.  I could parse the full error
>> message with regular expressions and use that to build my error message for
>> the user.  However, this turns out to be a lot of code and it also seems
>> like it could break down if a future update to Racket or some package
>> changes the wording of an error message.  I could go to the downstream
>> functions, remove their contracts and, instead, have them raise custom
>> exceptions.  Then catch those exceptions in the GUI code.  Not only is this
>> a lot of code to change but it seems wrong to start with code created
>> according to good practice and then undo it for further improvement.
>> >
>> > So my question is whether there is a better way to do this than I am
>> aware of?
>> >
>> > --
>> > 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.
>

-- 
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] Can someone help me solve a raco mystery?

[Gustavo Massaccesi]

 > 2) The error seems to happen on computers where I am switching some
package
> in the dependency graph from a catalog installation to a github repo
installation.
>  I'm not sure if this could contribute to raco deciding that two packages
with the
> same name are actually different and, for some reason, trying to update
them both.


I have no clue about what is happening here, but this part sounds
promising. For debugging, you can modify the in the file
pkg/private/install.rkt the function format-deps near
https://github.com/racket/racket/blob/master/racket/collects/pkg/private/install.rkt#L128
so it shows all the fields of the pkg-desc instead of showing only the name.

The definition is
(struct pkg-desc (source type name checksum auto? extra-path))

Gustavo

-- 
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] Re: SQL DB tooling

[Alex Harsanyi]

The package is called "north" and you can find it here:

https://pkgs.racket-lang.org/package/north

There is also the announcement on Reddit:

https://www.reddit.com/r/Racket/comments/akob56/ann_north_database_migrations/

Alex.


On Saturday, March 23, 2019 at 12:40:48 PM UTC+8, Aidan Gauland wrote:
>
> I see that Racket has a couple of nice libraries for talking to SQL 
> databases  and 
> , but I have been unable to find any 
> equivalent to the so-called "migrations" capability of DB libraries from 
> other languages (see 
>  and 
>   for examples).  Is there 
> anything like this for Racket, or even some language-agnostic, CLI tool 
> that does the same thing? 
>
> Thanks, 
> Aidan Gauland 
>
>

-- 
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.