arrayfire / arrayfire/arrayfire-lisp

Organization & Recommendations

Abierto
#1 4 comentarios 0 reacciones 0 asignados Ver en GitHub
Lenguaje dominante
Sin datos de lenguaje
Estrellas
2
Forks
3
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

Thanks for making this @pavanky I've forked the repo and since there is no other way for me to communicate with you or the other people who are watching this repo (Hi @umar456 and @shehzan10 ) I figured I'd open an issue and start there.

I don't know how much experience you or the other ppl have w/ Common Lisp, so I'll assume the answer is "very little" and if I'm wrong... then no harm done. I typically use a directory structure like the following for most projects:

```
arrayfire-lisp
|- arrayfire-lisp.asd
|- Readme.md
|- ...
|- examples
| `- examples.lisp
|- src
|- package.lisp
|- autowrap.lisp (if we're using cl-autowrap)
|- ...
`- spec
|- arrayfire.h (a header we write to make autowrap generation easier)
`- *.spec (the autowrap-generated spec files)
```

For the most part, if we use [cl-autowrap](https://github.com/rpav/cl-autowrap) and the C API of ArrayFire it should make life easier & faster. [cl-sdl2](https://github.com/lispgames/cl-sdl2) uses cl-autowrap completely and the SDL library is pretty extensive. I don't have any experience with the C portions of ArrayFire, but from looking at the docs, it looks pretty close.

As for style of the code, I try and stick to the [Google CL Style Guide](https://google.github.io/styleguide/lispguide.xml) but that's just me (and I'm not a style nazi... unless you're using tabs & spaces for indentation!!!)

If you want me to set the groundwork on directory structure & whatnot that's cool. Just let me know which direction I should take, or if you have questions let me know & I'll try to answer them.

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Línea de trabajo

The issue proposes an arrayfire-lisp.asd layout with examples/ and src/ files, plus cl-autowrap-generated specs, but it does not select a concrete change. Read the repository tree and README first, then confirm the maintainer's preferred directory structure and binding approach; the work is done only when that direction is agreed and a specific task is defined.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
c
Área
tooling
Tipo de issue
Nueva funcionalidad
Dificultad
5/5
Tiempo estimado
Más de una semana
Estado de actividad
Estancado
Claridad
Necesita aclaración
Aptitud para principiantes
15/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.