strange mkstemp! behavior

strange mkstemp! behavior

[Maarten Grachten]

Hi guile people,

in 1.6.4, but also in 1.7.1 (didn't try others)  there seems to be
something wrong when using mkstemp! several times after another like this:

(define (look-at-this x)
	(let ((name "/tmp/XXXXXX"))
		(write-line name)
		(mkstemp! name)))

(map look-at-this '(1 2 3))

shows:

/tmp/XXXXXX
/tmp/8rDXlK
standard input:2255:17: In procedure mkstemp! in expression (mkstemp!
name):
standard input:2255:17: Invalid argument
ABORT: (system-error)

So it seems that the variable name is not rebound to the value specified
in let. I am aware that mkstemp! writes into the string provided as an
argument, but I suppose that the value changed by mkstemp! should not
persist through different calls of the function. Am I wrong?

Any reaction much appreciated.

Maarten Grachten


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: strange mkstemp! behavior

[rm]

On Mon, Sep 13, 2004 at 10:24:27AM +0200, Maarten Grachten wrote:
> Hi guile people,
> 
> in 1.6.4, but also in 1.7.1 (didn't try others)  there seems to be
> something wrong when using mkstemp! several times after another like this:
> 
> (define (look-at-this x)
> 	(let ((name "/tmp/XXXXXX"))
> 		(write-line name)
> 		(mkstemp! name)))

I'm not a schemer, but doesn't the above code violate the specs?
'(let ((name "/tmp/XXXXXX"))' binds 'name' to an inmutable string
(string constants are inmutable).

How about:
 
 (define (look-at-this x)
    (let ((name (string-copy "/tmp/XXXXXX")))
      (write-line name)
      (mkstemp! name)))

On my system this produces:

 guile> (version )
 "1.6.4"
 guile> (map look-at-this '(1 2 3))
 /tmp/XXXXXX
 /tmp/XXXXXX
 /tmp/XXXXXX
 (#<input-output: /tmp/YoV3f2 3> #<input-output: /tmp/g5Etjk 4> #<input-output: /tmp/uX15kC 5>)
 guile>
 
 
HTH Ralf Mattes 



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: strange mkstemp! behavior

[Maarten Grachten]

Thanks RM!

On Mon, 13 Sep 2004 rm@fabula.de wrote:

> On Mon, Sep 13, 2004 at 10:24:27AM +0200, Maarten Grachten wrote:
> > Hi guile people,
> >
> > in 1.6.4, but also in 1.7.1 (didn't try others)  there seems to be
> > something wrong when using mkstemp! several times after another like this:
> >
> > (define (look-at-this x)
> > 	(let ((name "/tmp/XXXXXX"))
> > 		(write-line name)
> > 		(mkstemp! name)))
>
> I'm not a schemer, but doesn't the above code violate the specs?
> '(let ((name "/tmp/XXXXXX"))' binds 'name' to an inmutable string
> (string constants are inmutable).
>
> How about:
>
>  (define (look-at-this x)
>     (let ((name (string-copy "/tmp/XXXXXX")))
>       (write-line name)
>       (mkstemp! name)))
>
> On my system this produces:
>
>  guile> (version )
>  "1.6.4"
>  guile> (map look-at-this '(1 2 3))
>  /tmp/XXXXXX
>  /tmp/XXXXXX
>  /tmp/XXXXXX
>  (#<input-output: /tmp/YoV3f2 3> #<input-output: /tmp/g5Etjk 4> #<input-output: /tmp/uX15kC 5>)
>  guile>
>
>
> HTH Ralf Mattes
>

______________________________________________________________________________

  Maarten Grachten
  Institut d'Investigacio en Intel.ligencia Artificial, IIIA
  Spanish Scientific Research Council, CSIC
  Campus UAB
  08193 Bellaterra, Catalunya, Spain
  Ph.: +34 93 5809570         Fax.: +34 93 5809661
  maarten@iiia.csic.es
______________________________________________________________________________

Why limit the freedom of software development? Say `no' to software patents!
http://swpat.ffii.org


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: strange mkstemp! behavior

[Stephen Compall]

rm@fabula.de writes:

> I'm not a schemer, but doesn't the above code violate the specs?
> '(let ((name "/tmp/XXXXXX"))' binds 'name' to an inmutable string
> (string constants are inmutable).

You're right, but Guile treats them the same.  Maybe it was different
in R4RS.  Here's from R5RS:

 - procedure: string-set! string k char
     K must be a valid index of STRING .  `String-set!' stores CHAR in
     element K of STRING and returns an unspecified value.

     (define (f) (make-string 3 #\*))
     (define (g) "***")
     (string-set! (f) 0 #\?)                ==>  _unspecified_
     (string-set! (g) 0 #\?)                ==>  _error_

Note _unspecified_ means the form answers an unspecified value, not
that its behavior is unspecified.

--
Stephen Compall or s11 or sirian

Sin has many tools, but a lie is the handle which fits them all.

virus Craig Livingstone encryption Indigo SCUD missile espionage radar
plutonium Manfurov BROMURE sweep subversive Defcon Project Monarch
mailbomb


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: strange mkstemp! behavior

[Marius Vollmer]

Stephen Compall <s11@member.fsf.org> writes:

> rm@fabula.de writes:
>
>> I'm not a schemer, but doesn't the above code violate the specs?
>> '(let ((name "/tmp/XXXXXX"))' binds 'name' to an inmutable string
>> (string constants are inmutable).
>
> You're right, but Guile treats them the same.  Maybe it was different
> in R4RS. [...]

It is very easy now to implement read-only strings in Guile.  Should
we do so?  String literals and the the strings returned by
symbol->string would be read-only.  Anything else?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: strange mkstemp! behavior

[Stephen Compall]

Marius Vollmer <mvo@zagadka.de> writes:

> It is very easy now to implement read-only strings in Guile.  Should
> we do so?  String literals and the the strings returned by
> symbol->string would be read-only.  Anything else?

 - procedure: vector-set! vector k obj
     K must be a valid index of VECTOR.  `Vector-set!' stores OBJ in
     element K of VECTOR.  The value returned by `vector-set!' is
     unspecified.

     (let ((vec (vector 0 '(2 2 2 2) "Anna")))
       (vector-set! vec 1 '("Sue" "Sue"))
       vec)
               ==>  #(0 ("Sue" "Sue") "Anna")
     
     (vector-set! '#(0 1 2) 1 "doe")
               ==>  _error_  ; constant vector

 - procedure: set-car! pair obj
     Stores OBJ in the car field of PAIR.  The value returned by
     `set-car!' is unspecified.

     (define (f) (list 'not-a-constant-list))
     (define (g) '(constant-list))
     (set-car! (f) 3)                       ==>  _unspecified_
     (set-car! (g) 3)                       ==>  _error_

It's also an error to modify numbers and booleans, but I don't think
this is a problem.

The way it is now doesn't bother me at all.  One fewer detail is
usually good IMHO, barring other considerations.

--
Stephen Compall or s11 or sirian

Patch griefs with proverbs.
		-- William Shakespeare, "Much Ado About Nothing"

LLNL Dateline Consul NSA LABLINK Forte JPL plutonium lock picking
Ft. Bragg Area 51 S Key Qaddafi Leitrim defense information warfare


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: strange mkstemp! behavior

[Paul Jarc]

Marius Vollmer <mvo@zagadka.de> wrote:
> It is very easy now to implement read-only strings in Guile.  Should
> we do so?  String literals and the the strings returned by
> symbol->string would be read-only.  Anything else?

If symbol->string strings are read-only, and if literals are processed
by (symbol->string (string->symbol foo)), then we get shared storage
for literals too, reducing memory usage.  Do we care about making them
non-"eq?"?


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: strange mkstemp! behavior

[Marius Vollmer]

Stephen Compall <s11@member.fsf.org> writes:

> Marius Vollmer <mvo@zagadka.de> writes:
>
>> It is very easy now to implement read-only strings in Guile.  Should
>> we do so?  String literals and the the strings returned by
>> symbol->string would be read-only.  Anything else?
>
>  - procedure: vector-set! vector k obj

Yeah, right, that can come later.  But are there any other read-only
strings that we need to implement?

Actually, I'm now a bit in favor to leave the result of symbol->string
as copy-on-write.  It is a useful extension andjust as efficient as a
read-only string.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: strange mkstemp! behavior

[Kevin Ryde]

Marius Vollmer <mvo@zagadka.de> writes:
>
> String literals and the the strings returned by
> symbol->string would be read-only.

SCM_STRING_CHARS barfs on a read-only literal, badly breaking
guile-gtk for instance.  It can be updated, but there's likely to be
quite a bit of code using SCM_STRING_CHARS just to read.  Copy on
write would keep that working.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: strange mkstemp! behavior

[Marius Vollmer]

Kevin Ryde <user42@zip.com.au> writes:

> Marius Vollmer <mvo@zagadka.de> writes:
>>
>> String literals and the the strings returned by
>> symbol->string would be read-only.
>
> SCM_STRING_CHARS barfs on a read-only literal, badly breaking
> guile-gtk for instance.  It can be updated, but there's likely to be
> quite a bit of code using SCM_STRING_CHARS just to read.

Oops, right.  I will make string literals writable again, and put a
big comment on SCM_STRING_CHARS to make them read-only when
SCM_STRING_CHARS is removed.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: strange mkstemp! behavior

[Marius Vollmer]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:

> Kevin Ryde <user42@zip.com.au> writes:
>
>> Marius Vollmer <mvo@zagadka.de> writes:
>>>
>>> String literals and the the strings returned by
>>> symbol->string would be read-only.
>>
>> SCM_STRING_CHARS barfs on a read-only literal, badly breaking
>> guile-gtk for instance.  It can be updated, but there's likely to be
>> quite a bit of code using SCM_STRING_CHARS just to read.
>
> Oops, right.  I will make string literals writable again, and put a
> big comment on SCM_STRING_CHARS to make them read-only when
> SCM_STRING_CHARS is removed.

I think now that we need to go further, removing read-only strings
altogether until SCM_STRING_CHARS is removed.  A bit sad, but hey.

(The code will remain, but ifdefed out.)


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user