Re: [racket-dev] generic API names considered harmful

[Jay McCarthy]

I am one of the guilty. The dispatcher system uses 'make' everywhere
and I intend people to use prefix-in:

 (prefix-in lift: web-server/dispatchers/dispatch-lift)
 (prefix-in fsmap: web-server/dispatchers/filesystem-map)
 (prefix-in sequencer: web-server/dispatchers/dispatch-sequencer)
 (prefix-in files: web-server/dispatchers/dispatch-files)
 (prefix-in filter: web-server/dispatchers/dispatch-filter)
 (prefix-in servlets: web-server/dispatchers/dispatch-servlets)
 (prefix-in log: web-server/dispatchers/dispatch-log))

This was originally an attempt to make it so dispatchers would be
dynamically load-able, so they'd need to have a common name that the
outside could expect. After implementing it and having some time with
these, that didn't seem like a worthwhile idea anymore.

I basically agree with you Neil.

Jay

On Fri, Jul 4, 2014 at 5:30 PM, Neil Van Dyke n...@neilvandyke.org wrote:
 For documented public API of modules that are part of core Racket, shouldn't
 pretty much all the identifiers be descriptive enough to be unique within
 the scope of core Racket?  (Excepting name conflicts from SRFIs and teaching
 languages?)

 I've now noticed generic API names like make and render in core Racket
 modules written by, I think, 3 different very smart core Racket developers.
 I don't understand why we're still doing this. Was it for use with the
 unitssignatures (which are more trouble than they're worth, IMHO)?

 For code using these APIs, for readability (since any generic names in a
 module are relative to what that module is about, not the possibly many
 modules that module uses), I end up using prefix-in on modules with
 generic API names, which is still harder to read than natural identifiers.

 And even if I do the prefix-in like foo-lib:, with a colon on the end,
 foo-lib:make is still harder for someone reading the code to look up the
 identifier in Racket doc search, compared looking up a unique API identifier
 like make-foo or foo-make.

 Neil V.

 _
  Racket Developers list:
  http://lists.racket-lang.org/dev



-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Compile racket without native compare-and-swap support?

[Juan Francisco Cantero Hurtado]

On 07/03/14 10:07, Matthew Flatt wrote:

I've just built Racket for Linux on MIPS without problem, so I don't
think it's a misaligned access.


Thanks for take a look to the problem :)

Be aware linux has code in the kernel to fix misaligned access to 
memory. You can disable this behaviour in mips64 following this guide 
http://www.linux-mips.org/wiki/Alignment (or arm 
https://www.kernel.org/doc/Documentation/arm/mem_alignment).


Maybe the problem is in some of the code inside of some C macro related 
to OpenBSD.




I tried Linux because I found QEMU images that made it relatively
convenient to try:

   http://people.debian.org/~aurel32/qemu/mipsel/


I've compiled racket in qemu with that image and with the workarounds 
mentioned above disabled. Racket builds without problem. The same with 
linux/armv7.




If you can point me to similar images for OpenBSD, I'd be happy to take
a closer look.


I've been trying during the last days to run OpenBSD mips64/mips64el 
with qemu but I failed. I will try with other architectures.





At Wed, 18 Jun 2014 04:33:46 +0200, Juan Francisco Cantero Hurtado wrote:

Sorry for revive an old thread but recently an OpenBSD developer
(jturner) has been testing racket on mips64el (loonsong).

He sees a SIGBUS at the same point. GDB doesn't show a backtrace.

Maybe the interpreter is performing a misaligned access to the memory at
some point and the problem is not only related to the growing direction
of the stack. It can even hurt slightly the performance on other platforms.

HPPA and MIPS64 only permit aligned access to memory, however amd64, arm
(almost always) and x86 doesn't have this problem.

On 04/30/14 15:49, Juan Francisco Cantero Hurtado wrote:

On 04/30/14 02:07, Matthew Flatt wrote:

It's been a very long time since I touched a machine where the stack
grows up. Does changing `c-cont-buf.stack_size` to `c-stack_size`
work?


I'm not sure:

mkdir xsrc
make xsrc/precomp.h
env XFORM_PRECOMP=yes ../racketcgc  -cqu
/usr/ports/pobj/racket-6.0-debug/racket-6.0/src/racket/gc2/xform.rkt
--setup . --cpp cc -E -I./..
-I/usr/ports/pobj/racket-6.0-debug/racket-6.0/src/racket/gc2/../include
-I/usr/local/include -I/usr/X11R6/include -pthread -I/usr/local/include
 -DMZ_USES_SHARED_LIB   --keep-lines -o xsrc/precomp.h
/usr/ports/pobj/racket-6.0-debug/racket-6.0/src/racket/gc2/precomp.c
Segmentation fault (core dumped)

The output of gdb:
http://juanfra.info/bl/racket-2014/backtrace-racket-6.0.log



At Wed, 30 Apr 2014 00:21:10 +0200, Juan Francisco Cantero Hurtado wrote:

On 04/28/14 21:13, Matthew Flatt wrote:

Sorry --- I now see that `--enable-pthread` is forced for OpenBSD. I
think it should be on by default, but not actually forced, so I've made
that repair.

More to the point, I've pushed a repair so that CAS is attempted only
when futures or places are enabled.


I've compiled racket 6.0 with both patches. Now I see another
(unrelated) problem:

setjmpup.c: In function 'scheme_uncopy_stack'
setjmpup.c:358: error: 'struct Scheme_Cont' has no member named 'buf'

http://juanfra.info/bl/racket-2014/racket-6.0-3.log



At Mon, 28 Apr 2014 20:45:35 +0200, Juan Francisco Cantero Hurtado
wrote:

On 04/28/14 20:08, Matthew Flatt wrote:

I think `--enable-pthread` is triggering the attempt to use CAS. Can
you leave that one out?


I tried without enable-pthread. I see the same problem
http://juanfra.info/bl/racket-2014/racket-6.0-2.log



At Mon, 28 Apr 2014 19:59:10 +0200, Juan Francisco Cantero Hurtado
wrote:

On 04/28/14 01:03, Matthew Flatt wrote:

At Mon, 28 Apr 2014 00:58:48 +0200, Juan Francisco Cantero
Hurtado wrote:

I'm trying to compile Racket 6.0 on OpenBSD/hppa but the
compilation
fails because there is not support for CAS on OpenBSD/hppa. Is it
possible compile racket on platforms without atomic CAS?.


Does it help to use

  --disable-places --disable-futures

as arguments to `configure`?


No, I use always both arguments because we don't have support for
tls on
OpenBSD. Here is the log of the build:
http://juanfra.info/bl/racket-2014/racket-6.0.log



_
 Racket Developers list:
 http://lists.racket-lang.org/dev