Re: [racket-users] typed/rackunit and test-case
That's unfortunate. I'll wait until the next release and then try out test-case co. On Sunday, May 24, 2015 at 11:03:45 PM UTC-7, Alexis King wrote: Since test-case is a macro, require/typed won't help, and unfortunately, test-case doesn't work in Racket v6.1.1 (or earlier). It will be fixed in the upcoming release, or you can download a snapshot build from here: http://www.cs.utah.edu/plt/snapshots/ Otherwise, I don't think there's much you can do besides avoid test-case in earlier Racket versions. -- 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] typed/rackunit and test-case
Since test-case is a macro, require/typed won't help, and unfortunately, test-case doesn't work in Racket v6.1.1 (or earlier). It will be fixed in the upcoming release, or you can download a snapshot build from here: http://www.cs.utah.edu/plt/snapshots/ Otherwise, I don't think there's much you can do besides avoid test-case in earlier Racket versions. On May 24, 2015, at 22:59, Lehi Toskin lehi.tos...@gmail.com wrote: When using typed/rackunit, I find that using test-case doesn't seem to want to work properly. The code (test-case foo (check-true (string=? foo foo))) gives me several Type Checker errors that give me information I don't know what to do with. Is this something I need to require/typed for? -- 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] test amazes me
Matthias and Alexander Thanks for your responses. As I wrote: it is not a big problem. Now I am looking into rackunit and ( file:///C:/Program%20Files/Racket-6.2.900.3/doc/reference/require.html?q=te st#%28form._%28%28lib._racket%2Fprivate%2Fbase..rkt%29._planet%29%29 planet schematics/schemeunit:3). Jos _ From: Matthias Felleisen [mailto:matth...@ccs.neu.edu] Sent: lunes, 25 de mayo de 2015 3:37 To: Alexander D. Knauth Cc: Jos Koot; Racket-Users List Subject: Re: [racket-users] test amazes me I didn't implement test-engine but worked with Kathy to design and occasionally add features and/or maintain it. As you may know, in *SL the test-engine library runs (test) automatically when a programmer runs a program. That works out perfectly. I never imagined this library used for plain racket (though I do, knowing of its shortcomings) and I conjecture that Kathy factored the collection as an after-thought. So I wouldn't read too much into this -- Matthias On May 24, 2015, at 9:06 PM, Alexander D. Knauth wrote: Look at what this does: #lang racket (require test-engine/racket-tests) (check-expect 1 1) (check-expect 2 2) (check-expect 3 3) (check-expect (displayln hello) (displayln world)) (test) (test) Welcome to DrRacket, version 6.2.0.3--2015-05-17(542b960/a) [3m]. Language: racket [custom]; memory limit: 8182 MB. world hello All 4 tests passed! world hello All 8 tests passed! The test expressions are each evaluated twice, and each test passes a second time. I imagine this could be considered useful if for instance the tests depended on a mutable value and that value was mutated in between the runs of test, but was that the intention? I don't know. Also it appears to evaluate the second expression first and the first expression second. Weird. On May 24, 2015, at 6:42 PM, Jos Koot jos.k...@gmail.com wrote: #lang racket (module a racket (require test-engine/racket-tests) (check-expect 1 1) (test)) (module b racket (require test-engine/racket-tests) (check-expect 2 2) (test)) (require 'a 'b) This gives me: Welcome to DrRacket, version 6.2.900.3--2015-05-16(e8b52f6/a) [3m]. Language: racket [custom]; memory limit: 2000 MB. The only test passed! All 3 tests passed! Apparently test does not clear the list of tests already done. But even then I am surprised by seeing THREE tests passed. Without clearing the accumulated tests, I would expect: All TWO tests passed! Should test not eliminate the tests already done from the list of tests to be gathered in future? And how come (require 'a 'b) does THREE tests, not TWO? Is is not a big problem. I am just curious. Thanks, Jos -- 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.
[racket-users] Re: exn-string
If we have a racket/exn module, would the other exn structs then be placed there as well? -- 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] Simple Interdependent Units?
As I had to find out Racket's module system doesn't support cyclic dependencies. In that case I should use units. But as far as I have understood the concept of full fledged units I must either write a lot of redundant code like signature auto^, implementation auto@, import auto^, require auto.rkt, export auto^ etc OR I could create a lot of files following a certain naming conventions when using whole module units. Both approaches are more hassle than managing the respective files of my framework with copypaste and via include. Isn't there any simple way to declare cyclic dependencies? Can I put the signature and the implementation into one file? How do I require or import such an interdependent unit framework? Do I have to use invoke-unit or require or ...? -- 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] Flower Garden: Open Flowers
Il giorno 23/mag/2015, alle ore 19.28, Matthias Felleisen ha scritto: Why don't you put this into github and register it with the package server? Well, I tried to download git for my Mac twice. Two times it was interrupted after half of the 20MB version control monster had been downloaded. So, there won't be any repository on github because the webmob around G, my adblocker and ... some years ago downloads tended to fail at 99.99%. Never mind. Then I created the package as a plt file and uploaded it to the /planet/ server. Still it does not appear in the catalog of Dr. Racket's package manager while it can be found with the web interface. But it doesn't show the nice description I put into the description field. -- 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] Flower Garden: Open Flowers
You could also try other options for package sources, which includes things like .zip files and .plt files, in addition to github repositories. http://docs.racket-lang.org/pkg/Package_Concepts.html#%28part._concept~3asource%29 I have no experience with using anything other than a github repository though. You could also look at these: https://www.youtube.com/watch?v=jnPf6S0_6Xw http://con.racket-lang.org/2013/ On May 25, 2015, at 3:30 AM, Michael Tiedtke michael.tied...@o2online.de wrote: Il giorno 23/mag/2015, alle ore 19.28, Matthias Felleisen ha scritto: Why don't you put this into github and register it with the package server? Well, I tried to download git for my Mac twice. Two times it was interrupted after half of the 20MB version control monster had been downloaded. So, there won't be any repository on github because the webmob around G, my adblocker and ... some years ago downloads tended to fail at 99.99%. Never mind. Then I created the package as a plt file and uploaded it to the /planet/ server. Still it does not appear in the catalog of Dr. Racket's package manager while it can be found with the web interface. But it doesn't show the nice description I put into the description field. -- 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] typed/rackunit and test-case
The next release is in preparation. It should be out soon -- Matthias On May 25, 2015, at 2:11 AM, Lehi Toskin wrote: That's unfortunate. I'll wait until the next release and then try out test-case co. On Sunday, May 24, 2015 at 11:03:45 PM UTC-7, Alexis King wrote: Since test-case is a macro, require/typed won't help, and unfortunately, test-case doesn't work in Racket v6.1.1 (or earlier). It will be fixed in the upcoming release, or you can download a snapshot build from here: http://www.cs.utah.edu/plt/snapshots/ Otherwise, I don't think there's much you can do besides avoid test-case in earlier Racket versions. -- 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] Simple Interdependent Units?
Hi Michael, It would be interesting to hear about the situation that led to a cyclic dependency. The few cases where I have had a problem I managed to solve it by moving all structure definitions into a separate module structs.rkt and then requiring that module everywhere else. /Jens Axel 2015-05-25 11:52 GMT+02:00 Michael Tiedtke michael.tied...@o2online.de: As I had to find out Racket's module system doesn't support cyclic dependencies. In that case I should use units. But as far as I have understood the concept of full fledged units I must either write a lot of redundant code like *signature auto^*, *implementation auto@,* *import auto^*, *require auto.rkt,* *export auto^* etc OR I could create a lot of files following a certain naming conventions when using whole module units. Both approaches are more hassle than managing the respective files of my framework with copypaste and via *include.* *Isn't there any simple way to declare cyclic dependencies?* Can I put the signature and the implementation into one file? How do I require or import such an interdependent unit framework? Do I have to use invoke-unit or require or ...? -- 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] Simple Interdependent Units?
On May 25, 2015, at 5:52 AM, Michael Tiedtke wrote: As I had to find out Racket's module system doesn't support cyclic dependencies. In that case I should use units. But as far as I have understood the concept of full fledged units I must either write a lot of redundant code like signature auto^, implementation auto@, import auto^, require auto.rkt, export auto^ etc OR I could create a lot of files following a certain naming conventions when using whole module units. Both approaches are more hassle than managing the respective files of my framework with copypaste and via include. The whole point of units is to avoid copy and paste. (Indeed, the entire history of programming languages is abut avoiding copy and paste.) While I agree that units are syntactically somewhat more cumbersome, the overhead is tolerable in my opinion. Then again as a co-conspirator of units, you wouldn't expect me to say anything else. Warning: units have limited type support, and it's only being turned into code for HEAD now. Isn't there any simple way to declare cyclic dependencies? Most PLs don't have cyclic modules. (They may pretend to have modules but don't, which is why cyclic linking works.) The normal way of dealing with cyclic dependencies is to cut the static ties and replace them with dynamic ones, usually callbacks via lambdas and/or overriding in classes. Can I put the signature and the implementation into one file? Yes. How do I require or import such an interdependent unit framework? Do I have to use invoke-unit or require or ...? Let's call #lang-modules, compilation packages (CP) here. Units are run-time values. They are first-class, like numbers. They come with a range of operations, like booleans. These include: creation, linking, and invoking. You can also store them in containers. You can even print them: (displayln (unit (import) (export))) #unit:stdin::49 As such a CP can provide and require units. You can also protect units with contracts. Signatures are syntactic constructs. At run-time they are gone. The point of CPs is that you can provide and require syntactic constructs, too. So yes, you can provide and require signatures but it doesn't mean providing/requiring them at run-time. They are dealt with at compile time. At compile time, you can also manipulate signatures with operations such as extending them. (Perhaps there's nothing else.) ;; --- I recommend you make 3-line examples of signatures, units, linking expressions (compounds) and invocations -- all in one CP. Then you may wish to separate them into different CPs, without changing the syntax, just use require/provide. Finally you may wish to use the special CP languages for declaring signatures and units. And finally you want to play with inferred linking. Holler when you get stuck -- Matthias -- 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] exn-string
Maybe I'm over-thinking this and/or misunderstanding the use case, but: Should there maybe be a parameter to control whether exn-string returns anything interesting? And, should it be #f by default? Roughly, for example: ;; When current-exn-string-enabled? is #f -- the default -- ;; exn-string simply returns error. ;; ;; (The idea here is that net apps shouldn't provide this information ;; by default, exn-string is probably being used to provide debug ;; info, and this should be enabled intentionally not by default.) (define current-exn-string-enabled? (make-parameter #f)) ;; exn-string : (or/c exn any) - string (define (exn-string exn) (cond [(not (current-exn-string-enabled?)) error] [(exn? exn) (parameterize ([current-error-port (open-output-string)]) ((error-display-handler) (exn-message exn) exn) (get-output-string (current-error-port)))] [else (format ~s\n exn Admittedly, just because there's a switch to turn it on and off, doesn't mean people will use it. (Source: Use the web for a week and encounter .NET apps deployed to show debug stack traces on error.) But there should be a switch, so that people can forget to use it. :) Admittedly, most Racket web apps are probably not high-value targets, today. But they ought to be someday, so why not plan for that? Again, I'm sorry if I'm over-thinking this. -- 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] Simple Interdependent Units?
Il giorno 25/mag/2015, alle ore 14.43, Jens Axel Søgaard ha scritto: Hi Michael, It would be interesting to hear about the situation that led to a cyclic dependency. The few cases where I have had a problem I managed to solve it by moving all structure definitions into a separate module structs.rkt and then requiring that module everywhere else. /Jens Axel It's in Open Flowers (on the mailing list and on planet). I wouldn't even call it cyclic dependency but interdependent classes. Elsewhere (I found two threads about this subject on this mailing list) someone mentioned that the model-view (as in model view controller) paradigm leads to interdependent classes. Some call them framework which sustain themselves like a construction in euclidian geometry ... Specifically the cornerstones of the table mechanic (where one can put cards) are interdependent. One thing that I could cut out and put into its own module in its own file was a simple flower dialog which works like a color chooser with a hard coded callback sending a message to its hosting object. Where, on the other hand, I'm stuck with copypaste are the different layout classes but that might be due to my unwillingness to abstract layouts any further. Or it had to do with the problem of creating a super class. Right now I can't remember ... -- 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] Simple Interdependent Units?
Il giorno 25/mag/2015, alle ore 14.29, Matthias Felleisen ha scritto: On May 25, 2015, at 5:52 AM, Michael Tiedtke wrote: As I had to find out Racket's module system doesn't support cyclic dependencies. In that case I should use units. But as far as I have understood the concept of full fledged units I must either write a lot of redundant code like signature auto^, implementation auto@, import auto^, require auto.rkt, export auto^ etc OR I could create a lot of files following a certain naming conventions when using whole module units. Both approaches are more hassle than managing the respective files of my framework with copypaste and via include. The whole point of units is to avoid copy and paste. (Indeed, the entire history of programming languages is abut avoiding copy and paste.) While I agree that units are syntactically somewhat more cumbersome, the overhead is tolerable in my opinion. Then again as a co-conspirator of units, you wouldn't expect me to say anything else. Well, right now I consider include to be superior for my little program. Warning: units have limited type support, and it's only being turned into code for HEAD now. Isn't there any simple way to declare cyclic dependencies? Most PLs don't have cyclic modules. (They may pretend to have modules but don't, which is why cyclic linking works.) The normal way of dealing with cyclic dependencies is to cut the static ties and replace them with dynamic ones, usually callbacks via lambdas and/or overriding in classes. Most implementations of an Algorithmic Language Scheme do have no problem with interdependent modules. Pretending to have modules and recreating inheritance with encapsulation are two distinct things. I'd say as long as they allow to seperate and reunite scopes with fine grained control they should be considered viable approaches to modules systems. Tying them to the file level might even be a good idea. Recreating header files reminds me of m4. Cutting static ties means to change the logic of my program because of typographic needs, i.e. the file is become too big. Honestly, I do that a lot of times but I don't see the reason why I shouldn't dispatch on type just to create a module out of my abstract class. The only reason why one needs modules is source code management and that mostly happens in combination with files. Then one needs hygiene in the top level environment to not go back to the LISP era - but other module systems allow me to do that. Can I put the signature and the implementation into one file? Yes. How do I require or import such an interdependent unit framework? Do I have to use invoke-unit or require or ...? Let's call #lang-modules, compilation packages (CP) here. Units are run-time values. They are first-class, like numbers. They come with a range of operations, like booleans. These include: creation, linking, and invoking. You can also store them in containers. You can even print them: (displayln (unit (import) (export))) #unit:stdin::49 As such a CP can provide and require units. You can also protect units with contracts. Signatures are syntactic constructs. At run-time they are gone. The point of CPs is that you can provide and require syntactic constructs, too. So yes, you can provide and require signatures but it doesn't mean providing/requiring them at run-time. They are dealt with at compile time. At compile time, you can also manipulate signatures with operations such as extending them. (Perhaps there's nothing else.) Some self hosting environments one day might not even know about the distinction between compile time and run time anymore. As far as I remember the algorthmic language scheme was divided into to stages: reader and interpreter. Interestingly enough Racket's module system doesn't handle interdependencies well while it's reader does have no problems with applying procedures which are defined only later on in the text. Other implementations can cope with interdependent modules but fail(ed) when you tried to use something before its definition. ;; --- I recommend you make 3-line examples of signatures, units, linking expressions (compounds) and invocations -- all in one CP. Then you may wish to separate them into different CPs, without changing the syntax, just use require/provide. Finally you may wish to use the special CP languages for declaring signatures and units. And finally you want to play with inferred linking. Holler when you get stuck -- Matthias Yes, thanks again a lot. But for now I'm the lazy programmer stuck with include. -- 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
Re: [racket-users] Simple Interdependent Units?
On May 25, 2015, at 3:19 PM, Michael Tiedtke michael.tied...@o2online.de
wrote:
See, you're doing away with the class definitions and substitute them with
unit definitions.
This is what I meant when I wrote you recreated encapsulation and
inheritance. (Because
linking somehow resembles multiple inheritance.)
#lang racket/gui
(define-signature model^ (setter get))
(define-signature view^ (error))
;; decoupled model-view
(define model@
(unit (import view^)
(export model^)
(define model%
(class object%
(super-new)
(define the-number 12)
(define/public (setter v)
(when (or ( v 0) ( 0 100))
(error can't do that))
(displayln `(setting to ,v))
(set! the-number v))
(define/public (get)
the-number)))
(define model (new model%))
(define (setter v) (send model setter v))
(define (get) (send model get
(define view@
(unit (import model^)
(export view^)
(define view%
(class object%
(super-new)
(define frame (new frame% [width 100][height 200][label VW]))
(define vpane (new vertical-pane% [parent frame]))
(define value0 (get))
(define slide
(new slider%
[parent vpane] [label %]
[min-value 0] [init-value value0] [max-value 100]
[style '(vertical)]
[callback (lambda (self _e) (setter (send self
get-value)))]))
(define/public (error msg)
(displayln msg))
(send frame show #t)))
(define (error msg) (send view error msg))
(define view (new view%
(define completly-linked-program@
(compound-unit
(import)
(export)
(link
[((model : model^)) model@ view]
(((view : view^)) view@ model
(define (run)
(invoke-unit completly-linked-program@))
Include works best after a cutpaste operation on an over-grown file.
My favourite module system for now!
Please see previous email.
Yes, I was thinking about things like these in my other message. But
this alreaddy depends on the evaluation order which can be reversed.
Right in this example one would like to mix in lazy evaluation.
(define the-view
{with-lazy-evaluation (new view% #model: (new model% #view: the-view)) })
There is a difference between lazy evaluation and cyclic references.
And it's huge.
One might even think about an interpreter that automatically tries ...
See shared. That's NOT laziness. Repeat, it's NOT laziness.
Here is what it takes (in principle) to extend it to objects:
(define-syntax (object-shared stx)
(syntax-case stx (new)
[(_ [(x x-field (new x% [x-field_ x0]))
(y y-field (new y% [y-field_ y0]))]
body)
#'(letrec ([x (new x% [x-field '*undefined-x*])]
[y (new y% [y-field y0])])
(set-field! x-field x x0)
#;
(set-field! y-field y y0)
body)]))
(define the-view
(object-shared [(the-model view (new model% [view the-view]))
(the-view model (new view% [model the-model]))]
the-view))
Git pull request for complete extension welcome.
--
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] Generic collections in Racket
On Mon, May 25, 2015 at 12:48 AM, Alexis King lexi.lam...@gmail.com wrote: Depending on other design decisions, it make make sense to consider this an IDE issue. That is, maybe the best thing is to have some kind of interactive value in the REPL that lets the user have control over the effects. (And this doesn't just have to be via some kind of simplistic mouse clicking -- I think there is a lot of unexplored UI space here). I'd definitely be curious to see what you have in mind beyond some simplistic mouse clicking. It would be cool to convey more information about sequence values via DrRacket's capability to render snips. I can't say that I have real concrete ideas, but all of this work on live updating GUIs seems promising. There's a lot out there, but beyond the obvious suspects, check out Sean McDirmid's work. It may also make sense to explore constructs that control effects somehow so you can just run things. I recently hacked together a little GUI thingy for showing enumerations that just let them scroll by inside what looks like the normal enumeration print out and it works by sampling and caching the first 200 elements of the enumeration, but being careful about errors and to staying the user's side of the world during the cache population. It does evaluate things at the point displaying is happening, but people generally do not have much expectation about when those functions are evaluated, so it seems to work well as long as errors that happen are printed sanely. As for Daniel's point about the contract violation, I've pushed a change that makes `sequence?` into a custom flat contract, so that example now gives a more useful error message: (take 5 (list-vector (range 10))) take: contract violation expected: (and/c immutable? sequence?) given: '#(0 1 2 3 4 5 6 7 8 9), which is mutable However, this only works when the contract is used alone in a first-order way. It doesn't give a helpful error message when used with `first`, for example: (first (vector 0)) first: contract violation expected: (and/c sequence? (not/c empty?)) given: '#(0) which isn't: sequence? It would be possible in this case, of course, to create a `nonempty-sequence?` contract, but it still wouldn't work in other cases. Robby, do you know of any way I could provide this extra error reporting in more cases while still keeping `sequence?` a flat contract? I'm not completely sure I'm getting the point, but is this something that and/c would need to cooperate with? Like for it to recognize that sequence? (which maybe should be called sequence/c instead?) is itself and and/c and print nested ones better? Robby -- 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] Simple Interdependent Units?
Il giorno 25/mag/2015, alle ore 19.31, Matthias Felleisen ha scritto:
If you mean you want truly decoupled views and models, you'd end up in this
position:
#lang racket
;; decoupled model-view
(module model racket
(provide model%)
(define model%
(class object%
(init-field view)
(super-new)
(define the-number 12)
(define/public (setter v)
(when (or ( v 0) ( 0 100))
(send view error can't do that))
(set! the-number v))
(define/public (get)
the-number
(module view racket/gui
(provide view%)
(require (submod .. model))
(define view%
(class object%
(init-field model)
(define frame (new frame% [width 100][height 200][label VW]))
(define vpane (new vertical-pane% [parent frame]))
(define value0 (send model get))
(define slide
(new slider%
[parent vpane] [label %]
[min-value 0] [init-value value0] [max-value 100]
[style '(vertical)]))
(define/public (error msg)
(displayln msg))
(send frame show #t
;;
-
(require 'view 'model)
(define the-view (new view% [model (new model% [view the-view])]))
If you run this code and then call make-voew in the repl, you get an error
about the use of the value the-view before its initialization.
Yes, I was thinking about things like these in my other message. But
this alreaddy depends on the evaluation order which can be reversed.
Right in this example one would like to mix in lazy evaluation.
(define the-view
{with-lazy-evaluation (new view% #model: (new model% #view: the-view)) })
One might even think about an interpreter that automatically tries ...
;;
So here is how you do it with units:
#lang racket/gui
(define-signature model^ (setter get))
(define-signature view^ (error))
;; decoupled model-view
(define model@
(unit (import view^)
(export model^)
;; ---
(define the-number 12)
(define (setter v)
(when (or ( v 0) ( 0 100))
(error can't do that))
(displayln `(setting to ,v))
(set! the-number v))
(define (get)
the-number)))
(define view@
(unit (import model^)
(export view^)
(define frame (new frame% [width 100][height 200][label VW]))
(define vpane (new vertical-pane% [parent frame]))
(define value0 (get))
(define slide
(new slider%
[parent vpane] [label %]
[min-value 0] [init-value value0] [max-value 100]
[style '(vertical)]
[callback (lambda (self _e) (setter (send self get-value)))]))
(define (error msg)
(displayln msg))
;; run program run
(send frame show #t)))
(define completly-linked-program@
(compound-unit
(import)
(export)
(link
[((model : model^)) model@ view]
(((view : view^)) view@ model
(define (run)
(invoke-unit completly-linked-program@))
;; ---
See, you're doing away with the class definitions and substitute them with unit
definitions.
This is what I meant when I wrote you recreated encapsulation and inheritance.
(Because
linking somehow resembles multiple inheritance.)
Now if you just want two modules with classes that can send message to each
other, assuming that they get objects of the right kind, that's
straightforward:
#lang racket
(module a racket
(provide a%)
(define a%
(class object%
(super-new)
(define/public (mam a-b i)
(displayln `(in a ,i))
(when ( i 0)
(send a-b mbm this (- i 1)))
(module b racket
(provide b%)
(define b%
(class object%
(super-new)
(define/public (mbm an-a i)
(displayln `(in b ,i))
(when ( i 0)
(send an-a mam this (- i 1)))
(module main racket
(require (submod .. a) (submod .. b))
(define a (new a%))
(define b (new b%))
(send a mam b 1))
(require 'main)
With include I can do the following:
File: a-class.rkt
(define a-class
{class object%
(super-new)
(define/public (who what)
(cond ((is-a? what a-class) 'me)
((is-a? what b-class) 'not-me)))})
File: b-class .rkt
(define b-class
{class object%
(super-new)
(define a (new a-class))
(define/public (hello) 'hello-world)
(define/public (delegate-who what)
(send a who what)) })
File: c.rkt
(include (file a-class.rkt))
(include (file b-class.rkt))
Read Evaluate Print Loop:
(load Desktop/c.rkt) ; or equivalent path
(define a (new a-class))
(send a who a) = 'me
(define b (new b-class))
(send a who b) = 'not-me
(send b delegate-who b) = 'not-me
End of Session
When you try to declare two modules in the two files
Re: [racket-users] Simple Interdependent Units?
If you mean you want truly decoupled views and models, you'd end up in this position: #lang racket ;; decoupled model-view (module model racket (provide model%) (define model% (class object% (init-field view) (super-new) (define the-number 12) (define/public (setter v) (when (or ( v 0) ( 0 100)) (send view error can't do that)) (set! the-number v)) (define/public (get) the-number (module view racket/gui (provide view%) (require (submod .. model)) (define view% (class object% (init-field model) (define frame (new frame% [width 100][height 200][label VW])) (define vpane (new vertical-pane% [parent frame])) (define value0 (send model get)) (define slide (new slider% [parent vpane] [label %] [min-value 0] [init-value value0] [max-value 100] [style '(vertical)])) (define/public (error msg) (displayln msg)) (send frame show #t ;; - (require 'view 'model) (define the-view (new view% [model (new model% [view the-view])])) If you run this code and then call make-voew in the repl, you get an error about the use of the value the-view before its initialization. ;; So here is how you do it with units: #lang racket/gui (define-signature model^ (setter get)) (define-signature view^ (error)) ;; decoupled model-view (define model@ (unit (import view^) (export model^) ;; --- (define the-number 12) (define (setter v) (when (or ( v 0) ( 0 100)) (error can't do that)) (displayln `(setting to ,v)) (set! the-number v)) (define (get) the-number))) (define view@ (unit (import model^) (export view^) (define frame (new frame% [width 100][height 200][label VW])) (define vpane (new vertical-pane% [parent frame])) (define value0 (get)) (define slide (new slider% [parent vpane] [label %] [min-value 0] [init-value value0] [max-value 100] [style '(vertical)] [callback (lambda (self _e) (setter (send self get-value)))])) (define (error msg) (displayln msg)) ;; run program run (send frame show #t))) (define completly-linked-program@ (compound-unit (import) (export) (link [((model : model^)) model@ view] (((view : view^)) view@ model (define (run) (invoke-unit completly-linked-program@)) ;; --- Now if you just want two modules with classes that can send message to each other, assuming that they get objects of the right kind, that's straightforward: #lang racket (module a racket (provide a%) (define a% (class object% (super-new) (define/public (mam a-b i) (displayln `(in a ,i)) (when ( i 0) (send a-b mbm this (- i 1))) (module b racket (provide b%) (define b% (class object% (super-new) (define/public (mbm an-a i) (displayln `(in b ,i)) (when ( i 0) (send an-a mam this (- i 1))) (module main racket (require (submod .. a) (submod .. b)) (define a (new a%)) (define b (new b%)) (send a mam b 1)) (require 'main) On May 25, 2015, at 11:58 AM, Michael Tiedtke michael.tied...@o2online.de wrote: Il giorno 25/mag/2015, alle ore 14.43, Jens Axel Søgaard ha scritto: Hi Michael, It would be interesting to hear about the situation that led to a cyclic dependency. The few cases where I have had a problem I managed to solve it by moving all structure definitions into a separate module structs.rkt and then requiring that module everywhere else. /Jens Axel It's in Open Flowers (on the mailing list and on planet). I wouldn't even call it cyclic dependency but interdependent classes. Elsewhere (I found two threads about this subject on this mailing list) someone mentioned that the model-view (as in model view controller) paradigm leads to interdependent classes. Some call them framework which sustain themselves like a construction in euclidian geometry ... Specifically the cornerstones of the table mechanic (where one can put cards) are interdependent. One thing that I could cut out and put into its own module in its own file was a simple flower dialog which works like a color chooser with a hard coded callback sending a message to its hosting object. Where, on the other hand, I'm stuck with copypaste are the different layout classes but that might be due to my unwillingness to abstract layouts any further. Or it had to do with the problem of creating a super class. Right now I can't remember ... -- You received this message because you
Re: [racket-users] Generic collections in Racket
I recently hacked together a little GUI thingy for showing enumerations that just let them scroll by inside what looks like the normal enumeration print out and it works by sampling and caching the first 200 elements of the enumeration, but being careful about errors and to staying the user's side of the world during the cache population. It does evaluate things at the point displaying is happening, but people generally do not have much expectation about when those functions are evaluated, so it seems to work well as long as errors that happen are printed sanely. This sounds neat, although I'm not entirely sure I understand it properly. Do you have this somewhere I could take a look at? I'm not completely sure I'm getting the point, but is this something that and/c would need to cooperate with? Like for it to recognize that sequence? (which maybe should be called sequence/c instead?) is itself and and/c and print nested ones better? Robby Let me explain: the sequence? predicate is simply the predicate generated by define-generics, so it recognizes all things that are sequences. This includes everything that implements gen:sequence as well as all the defaults. This can be a little confusing, though, when it comes to mutable vectors or mutable hash tables. In the #:defaults clause, the predicate for recognizing vectors and hash tables are (conjoin vector? immutable?) and (conjoin hash? immutable?). This is the behavior I want, but it also means that trying to perform a sequence operation on a mutable vector gives a confusing error message. - (take 2 (vector 1 2 3 4)) ; take: contract violation ; expected: sequence? ; given: '#(1 2 3 4) ; in: the 2nd argument of ; (- ;exact-nonnegative-integer? ;sequence? ;sequence?) In that error message, it's entirely unclear what's wrong, especially since mutable vectors print the same way as immutable vectors. I want the actual behavior of sequence? to remain identical, but I'd like to improve the error reporting in these cases to help avoid confusion. This is the error message I've come up with. - (take 2 (vector 1 2 3 4)) ; take: contract violation ; expected: (and/c immutable? sequence?) ; given: '#(1 2 3 4), which is mutable ; in: the 2nd argument of ; (- ;exact-nonnegative-integer? ;sequence? ;sequence?) Perhaps that printout is misleading. The contract is not actually (and/c immutable? sequence?), it's just sequence?. Maybe it should say expected: sequence?, which must be immutable. Either way, this is an improvement over the opaque error reporting of the unmodified case. I've implemented this contract like so: (define sequence?* (make-flat-contract #:name 'sequence? #:first-order sequence? #:projection (λ (blame) (λ (val) (cond [(sequence? val) val] [(disjoin vector? hash?) ; raise a custom blame error ] [else ; raise the usual blame error ]) I've then provided sequence?* as sequence? via rename-out. However, and/c only uses the first-order check, which is still just plain sequence?, so contract errors where sequence? is used within a combinator are just as opaque as before. - (first (vector 1 2 3 4)) ; first: contract violation ; expected: (and/c sequence? (not/c empty?)) ; given: '#(1 2 3 4) ; which isn't: sequence? ; in: the 1st argument of ; (- (and/c sequence? (not/c empty?)) any) I'm not sure what the best solution to this problem is. Perhaps providing some extra information to and/c would be the right approach? Sorry for the long-winded explanation, I just need to make it clear that sequence? is really just a plain old predicate, but I've tacked a custom projection onto it for nicer blame errors. Alexis -- 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] Generic collections in Racket
Alexis, think of a lazy sequence as something that the rest of the program will explore. In addition to a GUI-based exploration, I would love to see a programmatic one. Imagine (explore-lazy lazy-sequence:exp strictness-pattern:exp) where (the value of) strictness-pattern is a function that pokes around lazy-sequence and displays. You could provide default strictness-pattern values and you could even provide strictness-patterns that dump values into a scrollable snip. But others could program their own strictness-patterns. The key would be to keep it simple. Note that contracts for lazy sequences could also check via strictness-patterns and memoize the exploration path. If the rest of the program re-explores it's cached in the proxy and if it goes beyond that exploration, consider it a contract violation. -- Matthias -- 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] Generic collections in Racket
At Sun, 24 May 2015 17:26:12 -0700, Alexis King wrote: 1. What if you do care about the order? IOW should there also be generic cons and snoc? Having a generic cons is a good idea, and I will consider a good way to incorporate it. However, there are lots of tradeoffs in various approaches, so let me try and outline those quickly. 1. The smaller the actual interface, the better. Right now, gen:sequence only contains five functions in it. This is fantastic for keeping code complexity down, and it heavily reduces the burden for implementing new collections. 2. The tradeoff, of course, is that adopting a one size fits all model loses possible optimization that can come out of more specific implementations. Maintaining efficiency in this case loses accuracy, as you've described. With fallback methods, you can get the best of both worlds. You can have a base set of methods that implementers of the interface need to write, and from which everything else can be derived. The derived methods can also be present in the interface, which allows implementers to override them if, e.g., their particular data structure can implement them more efficiently. For example, let's say you're implementing a vector-like data structure. You can implement, say, `map` efficiently by allocating a vector of the right size at the start, then filling it up. By overriding the `map` method, this more efficient version will be used instead of the fallback. The `set` library uses this pattern. Also, in my (admittedly limited) time so far with Clojure, I've sometimes been confused when eager collections automagically change into lazy sequences. If I add side effects (like debugging printfs) to code I don't realize is lazy, I utter many WTFs. I'm not sure to what extent that can happen with your library, but if it can, this might be good to point out in margin notes and examples. Yes, this is something I hope to probe out some more with user feedback. If someone uses it and runs into something really WTF-worthy, I'll certainly try and figure out what the right way to handle it is. Currently, everything that can return lazy sequences is noted in the API reference, but making it more prominent is a good idea. As for why the laziness is required to begin with, it's mostly just because lazy sequences are a very effective way of effectively implementing iterators without needing iterators. A lazy sequence can be turned into a concrete sequence with `extend`, and it doesn't need to allocate an entire intermediate sequence, which is quite appealing. FWIW, that's pretty close to what Racket's `sequence` datatype (not the interface) does. I haven't seen much code that uses them directly. Vincent -- 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] test amazes me
At Mon, 25 May 2015 08:03:22 +0200, Jos Koot wrote: Now I am looking into rackunit and (planet schematics/schemeunit:3). I believe the former is a descendant of the latter, so you're probably better off sticking to Rackunit. Vincent -- 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] Simple Interdependent Units?
Would lazy-require work here?
http://docs.racket-lang.org/reference/lazy-require.html
On Mon, May 25, 2015 at 3:56 PM, Matthias Felleisen matth...@ccs.neu.edu
wrote:
On May 25, 2015, at 3:19 PM, Michael Tiedtke michael.tied...@o2online.de
wrote:
See, you're doing away with the class definitions and substitute them
with unit definitions.
This is what I meant when I wrote you recreated encapsulation and
inheritance. (Because
linking somehow resembles multiple inheritance.)
#lang racket/gui
(define-signature model^ (setter get))
(define-signature view^ (error))
;; decoupled model-view
(define model@
(unit (import view^)
(export model^)
(define model%
(class object%
(super-new)
(define the-number 12)
(define/public (setter v)
(when (or ( v 0) ( 0 100))
(error can't do that))
(displayln `(setting to ,v))
(set! the-number v))
(define/public (get)
the-number)))
(define model (new model%))
(define (setter v) (send model setter v))
(define (get) (send model get
(define view@
(unit (import model^)
(export view^)
(define view%
(class object%
(super-new)
(define frame (new frame% [width 100][height 200][label VW]))
(define vpane (new vertical-pane% [parent frame]))
(define value0 (get))
(define slide
(new slider%
[parent vpane] [label %]
[min-value 0] [init-value value0] [max-value 100]
[style '(vertical)]
[callback (lambda (self _e) (setter (send self
get-value)))]))
(define/public (error msg)
(displayln msg))
(send frame show #t)))
(define (error msg) (send view error msg))
(define view (new view%
(define completly-linked-program@
(compound-unit
(import)
(export)
(link
[((model : model^)) model@ view]
(((view : view^)) view@ model
(define (run)
(invoke-unit completly-linked-program@))
Include works best after a cutpaste operation on an over-grown file.
My favourite module system for now!
Please see previous email.
Yes, I was thinking about things like these in my other message. But
this alreaddy depends on the evaluation order which can be reversed.
Right in this example one would like to mix in lazy evaluation.
(define the-view
{with-lazy-evaluation (new view% #model: (new model% #view: the-view))
})
There is a difference between lazy evaluation and cyclic references.
And it's huge.
One might even think about an interpreter that automatically tries ...
See shared. That's NOT laziness. Repeat, it's NOT laziness.
Here is what it takes (in principle) to extend it to objects:
(define-syntax (object-shared stx)
(syntax-case stx (new)
[(_ [(x x-field (new x% [x-field_ x0]))
(y y-field (new y% [y-field_ y0]))]
body)
#'(letrec ([x (new x% [x-field '*undefined-x*])]
[y (new y% [y-field y0])])
(set-field! x-field x x0)
#;
(set-field! y-field y y0)
body)]))
(define the-view
(object-shared [(the-model view (new model% [view the-view]))
(the-view model (new view% [model the-model]))]
the-view))
Git pull request for complete extension welcome.
--
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] Generic collections in Racket
With fallback methods, you can get the best of both worlds. You can have a base set of methods that implementers of the interface need to write, and from which everything else can be derived. The derived methods can also be present in the interface, which allows implementers to override them if, e.g., their particular data structure can implement them more efficiently. For example, let's say you're implementing a vector-like data structure. You can implement, say, `map` efficiently by allocating a vector of the right size at the start, then filling it up. By overriding the `map` method, this more efficient version will be used instead of the fallback. The `set` library uses this pattern. Yes, I agree, and I think another thing that will need to come along with this is a better set of documentation forms for generic interfaces. Currently, documenting generic interfaces is fairly ad- hoc, and expressing which methods are required and which are optional is unclear. FWIW, that's pretty close to what Racket's `sequence` datatype (not the interface) does. I haven't seen much code that uses them directly. I think this is mostly because the only way to create sequences is make-do-sequence, which is honestly terrible. As far as I can tell, it is neither more efficient nor more expressive than gen:stream, but the latter is far simpler and more natural to write. I don't really see the need for sequences in the racket/base sense, but streams are a good foundation for most lazy sequences, which is what I've employed for most of the lazy functionality I've used so far. -- 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] Simple Interdependent Units?
No.
On May 25, 2015, at 6:59 PM, Luke Whittlesey wrote:
Would lazy-require work here?
http://docs.racket-lang.org/reference/lazy-require.html
On Mon, May 25, 2015 at 3:56 PM, Matthias Felleisen matth...@ccs.neu.edu
wrote:
On May 25, 2015, at 3:19 PM, Michael Tiedtke michael.tied...@o2online.de
wrote:
See, you're doing away with the class definitions and substitute them with
unit definitions.
This is what I meant when I wrote you recreated encapsulation and
inheritance. (Because
linking somehow resembles multiple inheritance.)
#lang racket/gui
(define-signature model^ (setter get))
(define-signature view^ (error))
;; decoupled model-view
(define model@
(unit (import view^)
(export model^)
(define model%
(class object%
(super-new)
(define the-number 12)
(define/public (setter v)
(when (or ( v 0) ( 0 100))
(error can't do that))
(displayln `(setting to ,v))
(set! the-number v))
(define/public (get)
the-number)))
(define model (new model%))
(define (setter v) (send model setter v))
(define (get) (send model get
(define view@
(unit (import model^)
(export view^)
(define view%
(class object%
(super-new)
(define frame (new frame% [width 100][height 200][label VW]))
(define vpane (new vertical-pane% [parent frame]))
(define value0 (get))
(define slide
(new slider%
[parent vpane] [label %]
[min-value 0] [init-value value0] [max-value 100]
[style '(vertical)]
[callback (lambda (self _e) (setter (send self
get-value)))]))
(define/public (error msg)
(displayln msg))
(send frame show #t)))
(define (error msg) (send view error msg))
(define view (new view%
(define completly-linked-program@
(compound-unit
(import)
(export)
(link
[((model : model^)) model@ view]
(((view : view^)) view@ model
(define (run)
(invoke-unit completly-linked-program@))
Include works best after a cutpaste operation on an over-grown file.
My favourite module system for now!
Please see previous email.
Yes, I was thinking about things like these in my other message. But
this alreaddy depends on the evaluation order which can be reversed.
Right in this example one would like to mix in lazy evaluation.
(define the-view
{with-lazy-evaluation (new view% #model: (new model% #view: the-view)) })
There is a difference between lazy evaluation and cyclic references.
And it's huge.
One might even think about an interpreter that automatically tries ...
See shared. That's NOT laziness. Repeat, it's NOT laziness.
Here is what it takes (in principle) to extend it to objects:
(define-syntax (object-shared stx)
(syntax-case stx (new)
[(_ [(x x-field (new x% [x-field_ x0]))
(y y-field (new y% [y-field_ y0]))]
body)
#'(letrec ([x (new x% [x-field '*undefined-x*])]
[y (new y% [y-field y0])])
(set-field! x-field x x0)
#;
(set-field! y-field y y0)
body)]))
(define the-view
(object-shared [(the-model view (new model% [view the-view]))
(the-view model (new view% [model the-model]))]
the-view))
Git pull request for complete extension welcome.
--
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] Simple Interdependent Units?
Il giorno 25/mag/2015, alle ore 21.56, Matthias Felleisen ha scritto:
...
Yes, I was thinking about things like these in my other message. But
this alreaddy depends on the evaluation order which can be reversed.
Right in this example one would like to mix in lazy evaluation.
(define the-view
{with-lazy-evaluation (new view% #model: (new model% #view: the-view)) })
There is a difference between lazy evaluation and cyclic references.
And it's huge.
In the specific example lazy evaluation would do the job, though.
One might even think about an interpreter that automatically tries ...
See shared. That's NOT laziness. Repeat, it's NOT laziness.
Cyclic references or mutual hosting objects are not a problem at all.
It's only when you want the evualator handle that one line definition. But
a lazy evaluator solves this problem which a lot of people stumble over
as long as they have not yet adapted their way of thinking to the machine.
Here is what it takes (in principle) to extend it to objects:
(define-syntax (object-shared stx)
(syntax-case stx (new)
[(_ [(x x-field (new x% [x-field_ x0]))
(y y-field (new y% [y-field_ y0]))]
body)
#'(letrec ([x (new x% [x-field '*undefined-x*])]
[y (new y% [y-field y0])])
(set-field! x-field x x0)
#;
(set-field! y-field y y0)
body)]))
(define the-view
(object-shared [(the-model view (new model% [view the-view]))
(the-view model (new view% [model the-model]))]
the-view))
Sorry, ut I call it a workaround.
(define my-view (new view% #model: null))
(define my-model (new model% #view: null))
(send my-view set-model my-model)
(send my-model set-view my-view)
Every view should be able to handle a null or void model and every
model should be detachable from the view anyway.
--
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.
