Re: [racket-users] Can someone help me solve a raco mystery?

[Stephen Foster]

Thanks Gustavo,

That was a cool idea.  I enjoyed the opportunity to hack on some of the pkg
files.

Unfortunately, I wasn't able to reproduce the error today -- even on my
quarantined machine.  I'm not sure if that's because the error pattern
somewhat random or because I've been updating the repos for the
dependencies in question since I first noticed the error.

Anyway, I will definitely keep this in mind the next time I see this
error.  And I'll post if I figure out what's going on.  Thanks again!

--Stephen




On Sat, Mar 23, 2019 at 7:08 AM Gustavo Massaccesi 
wrote:

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

-- 


Stephen Foster
ThoughtSTEM Co-Founder
318-792-2035

-- 
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] CAM-2019 conference (St. Petersburg, July 22-24)

[Dmitry Pavlov]

### About CAM

Computer Assisted Mathematics conference is a forum for scientists
and teachers working in the area of algorithmic mathematics
and interested in promoting of important discrete mathematics
and theoretical informatics ideas into education in technical
universities and schools, including the development of computer
tools for supporting research and productive thinking.

About the conference: http://cam19.ipo.spb.ru/cam19/About_main/go/p

Requirements to submitted papers:
http://cam19.ipo.spb.ru/cam19/Submissions_main/go/p


### Important dates

Abstract submissions due: April 15, 2019

Paper submissions due: May 01, 2019

Conference: July 22-24, 2019


### Venue

Russia, St. Petersburg State Electrotechnical University “LETI”
https://etu.ru/en/university/


### Topics

There will be three sections:

1. Algorithmic Mathematics and Mathematical Modeling
2. Training in algorithmic mathematics and mathematical modeling
3. Computer tools to support teaching and studying of mathematics
   and computer science

The conference topics include but are not restricted to:

- Algorithmic mathematics
- Mathematical modeling
- Discrete analysis
- Control theory
- Theoretical computer science
- Symbolic computations
- Unsolved problems in theoretical and applied computer science
- Software engineering
- Computer aided education
- Software in math education and research
- Training in algorithmic mathematics and mathematical modeling
- Computer tools and teaching technologies to support productive
  thinking in mathematics and computer science


### Program committee

- Oleg Ivanov (chair), St.Petersburg State University, Russia
- Sergei Pozdniakov (co-chair), Saint Petersburg Electrotechnical
  University, Russia
- Nikolai Vasiliev (co-chair), PDMI of Russian Academy of Sciences,
  Russia

- Sergei Abramovich, State University of New York at Potsdam, USA
- Semjon Adlaj, FRCIС of Russian Academy of Sciences, Russia
- Alkiviadis Akritas, University of Thessaly, Greece
- Vladimir Dubrovsky, Moscow State University, Russia
- Viktor Freiman, Université de Moncton, Canada
- Dima Grigoriev, CNRS, Lille, France
- Juraj Hromkovic, ETH Zurich, Switzerland
- Mirjana Ivanovic, University of Novi Sad, Serbia
- Eugenijus Kurilovas, Vilnius Gediminas Technical University, Lithuania
- Yuri Matiyasevich, PDMI of Russian Academy of Sciences, Russia
- Christian Mercat, Claude Bernard University Lyon, France
- Dmitry Pavlov, IAA of Russian Academy of Sciences, Russia
- Michael Weigend, University of Münster, Germany
- Tatiana Mylläri, St.George’s University, Grenada, West Indies


### Registration and abstract submission

Abstract submission is done via EasyChair:
https://easychair.org/conferences/?conf=cam20190

(Paper submission has not opened yet.)


### Publications

Accepted papers will be published in the journal
“Computer Tools in Education” (CTE) and also in a new journal
“Computer Assisted Mathematics” which will open in 2019 and will
be the successor to CTE.
http://cte.eltech.ru/ojs/index.php/kio/about


### Fees

- Full: 250 €
- Student (Doctoral/PhD/graduate student): 100 €
- Student (Bachelors/Masters/undergraduate student): 75 €
- Accompanying person: 100 €
- Full for citizens of Russia and the CIS: 100 €

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

[James Platt]

On Mar 25, 2019, at 12:49 PM, Matthias Felleisen wrote:

> See how precise the exn message is: 2nd arg of 1st arg of f ~~ not a boolean? 

Okay.  So the exn message is generated in a systematic way which I can count 
on.  I didn't realize that.  Thanks.

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

[Matthias Felleisen]

> On Mar 25, 2019, at 12:30 PM, James Platt  wrote:
> 
> 
> On Mar 25, 2019, at 12:05 PM, Matthias Felleisen wrote:
> 
>> Your exception handlers may test a contract failure to any level. You can 
>> specify this in the predicate part of with-handlers or via match on the exn 
>> within the handler function. Regexp matching works well here. 
> 
> It's obvious enough how to use regex matching for this purpose.  My concern 
> is partly that it ends up being a lot of code to write and partly that I was 
> assuming that the exact wording of error message details could change with 
> updates.  Maybe these concerns are not so bad as I anticipate.  
> 
> From The Racket Guide, I did not get the impression that you could test a 
> contract at any level.  Specifically, I don't see how you tell which 
> parameter caused the error. It could just be me not understanding something 
> that is actually obvious in the docs or maybe the docs need some work.  As 
> usual, examples would help.  I did search the web for examples of Racket code 
> including "exn:fail:contract" and found very little. 

Welcome to Racket v7.2.0.10.
> (module a racket (provide (contract-out (f (-> (-> integer? boolean? string?) 
> string? (define (f g) (g 1 "not a bool")))
> (require 'a)
> (f (lambda (x y) "hello world"))
; f: broke its own contract
;   promised: boolean?
;   produced: "not a bool"
;   in: the 2nd argument of
;   the 1st argument of
;   (-> (-> integer? boolean? string?) string?)
;   contract from: a
;   blaming: a
;(assuming the contract is correct)
;   at: stdin:2.41
; [,bt for context]

See how precise the exn message is: 2nd arg of 1st arg of f ~~ not a boolean? 

And best of all you can get at it programmatically via exn-message: 

> (with-handlers ((exn:fail:contract? exn-message)) (f (lambda (x y) "hello 
> world")))
"f: broke its own contract\n  promised: boolean?\n  produced: \"not a bool\"\n  
in: the 2nd argument of\n  the 1st argument of\n  (-> (-> integer? 
boolean? string?) string?)\n  contract from: a\n  blaming: a\n   (assuming the 
contract is correct)\n  at: stdin:2.41"

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

[James Platt]

On Mar 25, 2019, at 12:05 PM, Matthias Felleisen wrote:

> Your exception handlers may test a contract failure to any level. You can 
> specify this in the predicate part of with-handlers or via match on the exn 
> within the handler function. Regexp matching works well here. 

It's obvious enough how to use regex matching for this purpose.  My concern is 
partly that it ends up being a lot of code to write and partly that I was 
assuming that the exact wording of error message details could change with 
updates.  Maybe these concerns are not so bad as I anticipate.  

>From The Racket Guide, I did not get the impression that you could test a 
>contract at any level.  Specifically, I don't see how you tell which parameter 
>caused the error. It could just be me not understanding something that is 
>actually obvious in the docs or maybe the docs need some work.  As usual, 
>examples would help.  I did search the web for examples of Racket code 
>including "exn:fail:contract" and found very little.

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

[Matthias Felleisen]

> On Mar 25, 2019, at 11:59 AM, James Platt  wrote:
> 
> 
> On Mar 23, 2019, at 5:49 PM, Greg Hendershott wrote:
> 
>> 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.).
> 
> Yes, but contract violations are also, by definition, problems that have been 
> anticipated.  You may not know why a function is, for example, being passed a 
> specific parameter that is the wrong data type or is empty when you said it 
> should be non-empty but you do know that that is what happened.  It's enough 
> to go on for an error message.  My hope was that contracts would provide a 
> more granular set of predicates to test for each of the possible violations.  



Your exception handlers may test a contract failure to any level. You can 
specify this in the predicate part of with-handlers or via match on the exn 
within the handler function. Regexp matching works well here. 

— Mattthias

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

[James Platt]

On Mar 23, 2019, at 5:49 PM, Greg Hendershott wrote:

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

Yes, but contract violations are also, by definition, problems that have been 
anticipated.  You may not know why a function is, for example, being passed a 
specific parameter that is the wrong data type or is empty when you said it 
should be non-empty but you do know that that is what happened.  It's enough to 
go on for an error message.  My hope was that contracts would provide a more 
granular set of predicates to test for each of the possible violations.  


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

[Aidan Gauland]

That looks like exactly what I want.  Thanks!

On 23/03/19 8:04 PM, Alex Harsanyi wrote:
>
> 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.

-- 
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] Generics: delegate to a parent

[hashim muqtadir]

> I am trying to make good use of Generic Interfaces, but can't figure out 
if its at all possible to delegate calls up the struct inheritance chain. 
So, something like `call-next`

If I understand you correctly, "define/generic" let you do this. See 
https://docs.racket-lang.org/reference/struct-generics.html?q=generic#%28form._%28%28lib._racket%2Fgeneric..rkt%29._define%2Fgeneric%29%29

> or even better maybe there's a way to do explicit dispatch? So something 
like having two structs:

If your structs don't inherit from each other, and no configuration of 
"fallback" or "default" options does what you want, a slightly different 
approach compared to extracting fish's implementation and reusing it is to 
use "define/generic" to get the existing "generic" function in your new 
struct's definition, and have a function convert a marlin to a fish, and 
then pass that over to the generic function.

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