Re: [racket-users] file-position does not extend file as expected

2019-06-24 Thread David Storrs
On Mon, Jun 24, 2019 at 5:19 PM Shu-Hung You <
shu-hung@eecs.northwestern.edu> wrote:

>
>
> FWIW, (write "foo") writes "\"foo\"" to the file. Maybe you want
> write-string or write-bytes?
>

*facepalm*

I think I want a better brain.  Thank you.


Matthew, thanks for the clarification about append mode.  Sure enough, as
soon as I take it out of 'append everything is fine.

Dave



>
>
> > On Mon, Jun 24, 2019 at 4:57 PM Jon Zeppieri  wrote:
> >>
> >> On Mon, Jun 24, 2019 at 4:51 PM Jon Zeppieri 
> wrote:
> >> >
> >> > `lseek` docs say:
> >> >
> >> > > The lseek() function shall allow the file offset to be set beyond
> the end of the existing data in the file. If data is later written at this
> point, subsequent reads of data in the gap shall return bytes with the
> value 0 until data is actually written into the gap.
> >> >
> >>
> >> And the Windows call `SetFilePosition` is similar:
> >>
> >> > It is not an error to set a file pointer to a position beyond the end
> of the file. The size of the file does not increase until you call the
> SetEndOfFile, WriteFile, or WriteFileEx function. A write operation
> increases the size of the file to the file pointer position plus the size
> of the buffer written, which results in the intervening bytes uninitialized.
> >
> > --
> > 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.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CAE8gKodw3c2wqUBdAPKRkX3hqin4fhZ8kjeFKh3LouFhY4-8XQ%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAE8gKodnAf5yo9P-HyU4pkCgeZDxKxtLmZ4XzP%2BRc0ugmFj3yA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] file-position does not extend file as expected

2019-06-24 Thread Shu-Hung You
On Mon, Jun 24, 2019 at 4:09 PM David Storrs  wrote:
>
> I actually did try writing something at the extended position, although I 
> removed it before posting the above.  Even with a write, it still does not do 
> as expected.  In fact, the results are even stranger:
>
> #lang racket
>
> (define (say . args) (displayln (apply ~a args)))
> (define the-path "./test-file")
> (when (file-exists? the-path)  (delete-file the-path))
> (say "before open, file exists?: " (file-exists? the-path))
>
> (let ([the-port (open-output-file the-path #:mode 'binary #:exists 'append)])
>   (say "after open, file exists?: " (file-exists? the-path))
>   (say "before repos, file size, position: " (file-size the-path) ", "
>(file-position the-port))
>   (file-position the-port 1000); should extend the file and fill the 
> intervening space with 0
>   (say "before flush, file size, position: " (file-size the-path) ", "
>(file-position the-port))
>   (flush-output the-port) ; ensure that the filling 0s have been written, 
> just to be sure
>   (say "before write, file size, position: " (file-size the-path) ", "
>(file-position the-port))
>
>   (write "foo" the-port)
>   (say "before 2nd flush, file size, position: "
>(file-size the-path) ", " (file-position the-port))
>   (flush-output the-port)
>   (say "finally, file size, position: " (file-size the-path) ", " 
> (file-position the-port))
>   )
> Ouptut:
>
> before open, file exists?: #f
> after open, file exists?: #t
> before repos, file size, position: 0, 0
> before flush, file size, position: 0, 1000
> before write, file size, position: 0, 1000
> before 2nd flush, file size, position: 0, 1005
> finally, file size, position: 5, 5
>
> Personally, i find this even weirder.  I wrote 3 characters, so why is the 
> file size 5?  (Which it is, on disk.)
>

FWIW, (write "foo") writes "\"foo\"" to the file. Maybe you want
write-string or write-bytes?



> On Mon, Jun 24, 2019 at 4:57 PM Jon Zeppieri  wrote:
>>
>> On Mon, Jun 24, 2019 at 4:51 PM Jon Zeppieri  wrote:
>> >
>> > `lseek` docs say:
>> >
>> > > The lseek() function shall allow the file offset to be set beyond the 
>> > > end of the existing data in the file. If data is later written at this 
>> > > point, subsequent reads of data in the gap shall return bytes with the 
>> > > value 0 until data is actually written into the gap.
>> >
>>
>> And the Windows call `SetFilePosition` is similar:
>>
>> > It is not an error to set a file pointer to a position beyond the end of 
>> > the file. The size of the file does not increase until you call the 
>> > SetEndOfFile, WriteFile, or WriteFileEx function. A write operation 
>> > increases the size of the file to the file pointer position plus the size 
>> > of the buffer written, which results in the intervening bytes 
>> > uninitialized.
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/CAE8gKodw3c2wqUBdAPKRkX3hqin4fhZ8kjeFKh3LouFhY4-8XQ%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAMTzy%2BbV-SExfSR6LSXX7r_Zpg7gD37LROf__o8C9HxpykaFNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] file-position does not extend file as expected

2019-06-24 Thread Matthew Flatt
I think that part is because you've opened the file in 'append mode.

At the OS level, 'append means "move to the end of the file before each
write". So, 'append and `file-position` to extend a file size just
don't work helpfully together.

I'll improve the docs.

At Mon, 24 Jun 2019 17:09:05 -0400, David Storrs wrote:
> I actually did try writing something at the extended position, although I
> removed it before posting the above.  Even with a write, it still does not
> do as expected.  In fact, the results are even stranger:
> 
> #lang racket
> 
> (define (say . args) (displayln (apply ~a args)))
> (define the-path "./test-file")
> (when (file-exists? the-path)  (delete-file the-path))
> (say "before open, file exists?: " (file-exists? the-path))
> 
> (let ([the-port (open-output-file the-path #:mode 'binary #:exists
> 'append)])
>   (say "after open, file exists?: " (file-exists? the-path))
>   (say "before repos, file size, position: " (file-size the-path) ", "
>(file-position the-port))
>   (file-position the-port 1000); should extend the file and fill the
> intervening space with 0
>   (say "before flush, file size, position: " (file-size the-path) ", "
>(file-position the-port))
>   (flush-output the-port) ; ensure that the filling 0s have been written,
> just to be sure
>   (say "before write, file size, position: " (file-size the-path) ", "
>(file-position the-port))
> 
>   (write "foo" the-port)
>   (say "before 2nd flush, file size, position: "
>(file-size the-path) ", " (file-position the-port))
>   (flush-output the-port)
>   (say "finally, file size, position: " (file-size the-path) ", "
> (file-position the-port))
>   )
> Ouptut:
> 
> before open, file exists?: #f
> after open, file exists?: #t
> before repos, file size, position: 0, 0
> before flush, file size, position: 0, 1000
> before write, file size, position: 0, 1000
> before 2nd flush, file size, position: 0, 1005
> finally, file size, position: 5, 5
> 
> Personally, i find this even weirder.  I wrote 3 characters, so why is the
> file size 5?  (Which it is, on disk.)
> 
> On Mon, Jun 24, 2019 at 4:57 PM Jon Zeppieri  wrote:
> 
> > On Mon, Jun 24, 2019 at 4:51 PM Jon Zeppieri  wrote:
> > >
> > > `lseek` docs say:
> > >
> > > > The lseek() function shall allow the file offset to be set beyond the
> > end of the existing data in the file. If data is later written at this
> > point, subsequent reads of data in the gap shall return bytes with the
> > value 0 until data is actually written into the gap.
> > >
> >
> > And the Windows call `SetFilePosition` is similar:
> >
> > > It is not an error to set a file pointer to a position beyond the end of
> > the file. The size of the file does not increase until you call the
> > SetEndOfFile, WriteFile, or WriteFileEx function. A write operation
> > increases the size of the file to the file pointer position plus the size
> > of the buffer written, which results in the intervening bytes uninitialized.
> >
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/CAE8gKodw3c2wqUBdAPKRkX3hqin4fhZ
> 8kjeFKh3LouFhY4-8XQ%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/5d113d6e.1c69fb81.e831a.85afSMTPIN_ADDED_MISSING%40gmr-mx.google.com.
For more options, visit https://groups.google.com/d/optout.


[racket-users] Call for Participation: ICFP 2019

2019-06-24 Thread 'Sam Tobin-Hochstadt' via users-redirect
=

Call for Participation

ICFP 2019
24th ACM SIGPLAN International Conference on Functional Programming
and affiliated events

August 18 - August 23, 2019
Berlin, Germany
http://icfp19.sigplan.org/

Early Registration until July 18!

=

ICFP provides a forum for researchers and developers to hear
about the latest work on the design, implementations, principles, and
uses of functional programming. The conference covers the entire
spectrum of work, from practice to theory, including its peripheries.

This year, ICFP is co-located with BOBKonf!

  * Overview and affiliated events:
http://icfp19.sigplan.org/home

  * Program:
http://icfp19.sigplan.org/program/program-icfp-2019

  * Accepted papers:
http://icfp19.sigplan.org/track/icfp-2019-papers

  * Registration is available via:
https://regmaster4.com/2019conf/ICFP19/register.php
Early registration ends 18 July, 2019.

  * Programming contest:
https://icfpcontest2019.github.io/

  * Student Research Competition:
https://icfp19.sigplan.org/track/icfp-2019-Student-Research-Competition

  * Follow us on Twitter for the latest news:
http://twitter.com/icfp_conference

In addition to BOBKonf (8/21), there are several events co-located with ICFP:

  * Erlang Workshop (8/18)
  * Functional Art, Music, Modeling and Design (8/23)
  * Functional High-Performance and Numerical Computing (8/18)
  * Haskell Implementors' Workshop (8/23)
  * Haskell Symposium (8/22-8/23)
  * miniKanren Workshop (8/22)
  * ML Family Workshop (8/22)
  * OCaml Workshop (8/23)
  * Programming Languages Mentoring Workshop (8/18)
  * Scheme Workshop (8/18)
  * Type-Driven Development (8/18)

### ICFP Organizers

General Chair: Derek Dreyer (MPI-SWS, Germany)

Artifact Evaluation Co-Chairs: Simon Marlow (Facebook, UK)
Industrial Relations Chair: Alan Jeffrey (Mozilla Research, USA)
Programming Contest Organiser: Ilya Sergey (Yale-NUS College, Singapore)
Publicity and Web Chair: Sam Tobin-Hochstadt (Indiana University, USA)
Student Research Competition Chair: William J. Bowman (University of British 
Columbia, Canada)
Workshops Co-Chair: Christophe Scholliers (Universiteit Gent, Belgium)
Jennifer Hackett (University of Nottingham, UK)
Conference Manager: Annabel Satin (P.C.K.)


### PACMPL Volume 3, Issue ICFP 2019

Principal Editor: François Pottier (Inria, France)

Review Committee:

Lennart Beringer (Princeton University, United States)
Joachim Breitner (DFINITY Foundation, Germany)
Laura M. Castro (University of A Coruña, Spain)
Ezgi Çiçek (Facebook London, United Kingdom)
Pierre-Evariste Dagand (LIP6/CNRS, France)
Christos Dimoulas (Northwestern University, United States)
Jacques-Henri Jourdan (CNRS, LRI, Université Paris-Sud, France)
Andrew Kennedy (Facebook London, United Kingdom)
Daan Leijen (Microsoft Research, United States)
Kazutaka Matsuda (Tohoku University, Japan)
Bruno C. d. S. Oliveira (University of Hong Kong, China)
Klaus Ostermann (University of Tübingen, Germany)
Jennifer Paykin (Galois, United States)
Frank Pfenning (Carnegie Mellon University, USA)
Mike Rainey (Indiana University, USA)
Chung-chieh Shan (Indiana University, USA)
Sam Staton (University of Oxford, UK)
Pierre-Yves Strub (Ecole Polytechnique, France)
German Vidal (Universitat Politecnica de Valencia, Spain)

External Review Committee:

Michael D. Adams  (University of Utah, USA)
Robert Atkey  (University of Strathclyde, IK)
Sheng Chen  (University of Louisiana at Lafayette, USA)
James Cheney  (University of Edinburgh, UK)
Adam Chlipala  (Massachusetts Institute of Technology, USA)
Evelyne Contejean (LRI, Université Paris-Sud, France) 
Germán Andrés Delbianco  (IRIF, Université Paris Diderot, France)
Dominique Devriese  (Vrije Universiteit Brussel, Belgium)
Richard A. Eisenberg  (Bryn Mawr College, USA)
Conal Elliott  (Target, USA)
Sebastian Erdweg  (Delft University of Technology, Netherlands)
Michael Greenberg  (Pomona College, USA)
Adrien Guatto  (IRIF, Université Paris Diderot, France)
Jennifer Hackett  (University of Nottingham, UK)
Troels Henriksen  (University of Copenhagen, Denmark)
Chung-Kil Hur  (Seoul National University, Republic of Korea)
Roberto Ierusalimschy  (PUC-Rio, Brazil)
Ranjit Jhala  (University of California, San Diego, USA)
Ralf Jung  (MPI-SWS, Germany)
Ohad Kammar  (University of Oxford, UK)
Oleg Kiselyov (Tohoku University, Japan)
Hsiang-Shang ‘Josh’ Ko  (National Institute of Informatics, Japan)
Ondřej Lhoták  (University of Waterloo, Canada)
Dan Licata  (Wesleyan University, USA)
Geoffrey Mainland  (Drexel University, USA)
Simon Marlow  (Facebook, UK)
Akimasa Morihata  (University of Tokyo, Japan)
Shin-Cheng Mu  (Academia Sinica, Taiwan)
Guillaume Munch-Maccagnoni  (Inria, France)
Kim Nguyễn  (University of Paris-Sud, France)
Ulf Norell  (Gothenburg University, Sweden)
Atsushi 

Re: [racket-users] file-position does not extend file as expected

2019-06-24 Thread David Storrs
I actually did try writing something at the extended position, although I
removed it before posting the above.  Even with a write, it still does not
do as expected.  In fact, the results are even stranger:

#lang racket

(define (say . args) (displayln (apply ~a args)))
(define the-path "./test-file")
(when (file-exists? the-path)  (delete-file the-path))
(say "before open, file exists?: " (file-exists? the-path))

(let ([the-port (open-output-file the-path #:mode 'binary #:exists
'append)])
  (say "after open, file exists?: " (file-exists? the-path))
  (say "before repos, file size, position: " (file-size the-path) ", "
   (file-position the-port))
  (file-position the-port 1000); should extend the file and fill the
intervening space with 0
  (say "before flush, file size, position: " (file-size the-path) ", "
   (file-position the-port))
  (flush-output the-port) ; ensure that the filling 0s have been written,
just to be sure
  (say "before write, file size, position: " (file-size the-path) ", "
   (file-position the-port))

  (write "foo" the-port)
  (say "before 2nd flush, file size, position: "
   (file-size the-path) ", " (file-position the-port))
  (flush-output the-port)
  (say "finally, file size, position: " (file-size the-path) ", "
(file-position the-port))
  )
Ouptut:

before open, file exists?: #f
after open, file exists?: #t
before repos, file size, position: 0, 0
before flush, file size, position: 0, 1000
before write, file size, position: 0, 1000
before 2nd flush, file size, position: 0, 1005
finally, file size, position: 5, 5

Personally, i find this even weirder.  I wrote 3 characters, so why is the
file size 5?  (Which it is, on disk.)

On Mon, Jun 24, 2019 at 4:57 PM Jon Zeppieri  wrote:

> On Mon, Jun 24, 2019 at 4:51 PM Jon Zeppieri  wrote:
> >
> > `lseek` docs say:
> >
> > > The lseek() function shall allow the file offset to be set beyond the
> end of the existing data in the file. If data is later written at this
> point, subsequent reads of data in the gap shall return bytes with the
> value 0 until data is actually written into the gap.
> >
>
> And the Windows call `SetFilePosition` is similar:
>
> > It is not an error to set a file pointer to a position beyond the end of
> the file. The size of the file does not increase until you call the
> SetEndOfFile, WriteFile, or WriteFileEx function. A write operation
> increases the size of the file to the file pointer position plus the size
> of the buffer written, which results in the intervening bytes uninitialized.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAE8gKodw3c2wqUBdAPKRkX3hqin4fhZ8kjeFKh3LouFhY4-8XQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] file-position does not extend file as expected

2019-06-24 Thread Jon Zeppieri
On Mon, Jun 24, 2019 at 4:51 PM Jon Zeppieri  wrote:
>
> `lseek` docs say:
>
> > The lseek() function shall allow the file offset to be set beyond the end 
> > of the existing data in the file. If data is later written at this point, 
> > subsequent reads of data in the gap shall return bytes with the value 0 
> > until data is actually written into the gap.
>

And the Windows call `SetFilePosition` is similar:

> It is not an error to set a file pointer to a position beyond the end of the 
> file. The size of the file does not increase until you call the SetEndOfFile, 
> WriteFile, or WriteFileEx function. A write operation increases the size of 
> the file to the file pointer position plus the size of the buffer written, 
> which results in the intervening bytes uninitialized.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAKfDxxzx%3DiL-JQkJBx_SC%2BF05kG%2BUMW%2Bn%2BNWfsaDorvHcCdzkw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] file-position does not extend file as expected

2019-06-24 Thread Jon Zeppieri
I *think* that the docs are wrong here. `file-position` maps onto
`lseek` on posix systems (pretty sure about this after a quick perusal
of the code) and `lseek` docs say:

> The lseek() function shall allow the file offset to be set beyond the end of 
> the existing data in the file. If data is later written at this point, 
> subsequent reads of data in the gap shall return bytes with the value 0 until 
> data is actually written into the gap.

So the file isn't really extended until you write something at that
position. But I'm sure Matthew can dive a definitive answer here.

- Jon




On Mon, Jun 24, 2019 at 4:31 PM David Storrs  wrote:
>
> Consider the following test script:
>
> #lang racket
>
> (define (say . args) (displayln (apply ~a args)))
> (define the-path "./test-file")
> (when (file-exists? the-path)  (delete-file the-path))
> (say "before open, file exists?: " (file-exists? the-path))
>
> (let ([the-port (open-output-file the-path #:mode 'binary #:exists 'append)])
>   (say "after open, file exists?: " (file-exists? the-path))
>   (say "file size, position: " (file-size the-path) ", " (file-position 
> the-port))
>   (file-position the-port 1000); should extend the file and fill the 
> intervening space with 0
>   (say "file size, position: " (file-size the-path) ", " (file-position 
> the-port))
>   (flush-output the-port) ; ensure that the filling 0s have been written, 
> just to be sure
>   (say "file size, position: " (file-size the-path) ", " (file-position 
> the-port)))
>
>
> The output is:
>
> before open, file exists?: #f
> after open, file exists?: #t
> file size, position: 0, 0
> file size, position: 0, 1000
> file size, position: 0, 1000
>
> The file on disk is in fact 0B long.  The docs for file-position 
> (https://docs.racket-lang.org/reference/port-buffers.html#%28def._%28%28quote._~23~25kernel%29._file-position%29%29)
>  include the following:
>
> "When file-position sets the position pos beyond the current size of an 
> output file or (byte) string, the file/string is enlarged to size pos and the 
> new region is filled with 0 bytes. If pos is beyond the end of an input file 
> or (byte) string, then reading thereafter returns eof without changing the 
> port’s position."
>
> Given the above, I was expecting the file to end up being 1000 bytes.  I'm 
> using Racket 7.1 on OSX 10.11; is this an OS issue or am I misunderstanding 
> something about Racket?
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/CAE8gKofKWtAKU4ZQk6ai-ydZx7WmY8%3D1GwDUFbW15BpxUSQ1qw%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAKfDxxw0cj%3D2EJBN2gjRjCGiYELrhhMxAz4-tuB%3DuoDX-phoBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[racket-users] file-position does not extend file as expected

2019-06-24 Thread David Storrs
Consider the following test script:

#lang racket

(define (say . args) (displayln (apply ~a args)))
(define the-path "./test-file")
(when (file-exists? the-path)  (delete-file the-path))
(say "before open, file exists?: " (file-exists? the-path))

(let ([the-port (open-output-file the-path #:mode 'binary #:exists
'append)])
  (say "after open, file exists?: " (file-exists? the-path))
  (say "file size, position: " (file-size the-path) ", " (file-position
the-port))
  (file-position the-port 1000); should extend the file and fill the
intervening space with 0
  (say "file size, position: " (file-size the-path) ", " (file-position
the-port))
  (flush-output the-port) ; ensure that the filling 0s have been written,
just to be sure
  (say "file size, position: " (file-size the-path) ", " (file-position
the-port)))


The output is:

before open, file exists?: #f
after open, file exists?: #t
file size, position: 0, 0
file size, position: 0, 1000
file size, position: 0, 1000

The file on disk is in fact 0B long.  The docs for file-position (
https://docs.racket-lang.org/reference/port-buffers.html#%28def._%28%28quote._~23~25kernel%29._file-position%29%29)
include the following:

"When file-position

sets the position pos beyond the current size of an output file or (byte)
string, the file/string is enlarged to size pos and the new region is
filled with 0 bytes. If pos is beyond the end of an input file or (byte)
string, then reading thereafter returns eof

without changing the port’s position."

Given the above, I was expecting the file to end up being 1000 bytes.  I'm
using Racket 7.1 on OSX 10.11; is this an OS issue or am I misunderstanding
something about Racket?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAE8gKofKWtAKU4ZQk6ai-ydZx7WmY8%3D1GwDUFbW15BpxUSQ1qw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[racket-users] Re: Creating movable Fonts on a Canvas

2019-06-24 Thread Amir Teymuri
Wow, this is a great blog! Many Thanks!

On Monday, June 24, 2019 at 2:52:35 AM UTC+2, Alex Harsanyi wrote:
>
> Have a look at the `snip%` and `pasteboard%` classes: you can represent 
> each glyph using a `snip%` and the pasteboard will handle the moving it 
> with the mouse.  You can derive the `snip%` and `pasteboard%` objects to 
> add new functionality -- this is easier than implementing a mouse move 
> operation using the `canvas%`  `on-event` method.
>
> While not exactly what you need, I wrote a blog post about using `snip%` 
> objects, and in the first example, the chess pieces themselves are actually 
> Unicode Glyphs, so you could easily modify it to have different 
> Glyphs/Letters that can be moved around in a canvas:
>
>
> https://alex-hhh.github.io/2018/10/chess-game-using-racket-s-pasteboard.html
>
> Alex.
>
> On Monday, June 24, 2019 at 4:40:34 AM UTC+8, Amir Teymuri wrote:
>>
>> If i want to use fonts on a canvas in a way that each single Glyph/Font 
>> is movable around the canvas by mouse, is it a good idea to have a class 
>> drivative of canvas% for each new font and then override the on-event 
>> method of them to update its coordinates on the main canvas? Or is there a 
>> better more effiicient way for doing this?
>>
>> Greetings,
>> Amir
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/b5e149fc-87c5-4ac0-9e09-90d058e4f56e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.