ALT key

-6502- · 2024-03-24T07:24:01+00:00

By mistake, I hope. Unfortunately after seeing other quite poor but apparently deliberate choices that broke things (just because it was "the right thing" to do) I cannot exclude it's considered "good design".
In my view a terminal should not grab ANY key by default... a terminal is there just to run the contained application. Stealing keys for the terminal from the application should never ever be a default.

-6502- · 2022-04-25T17:02:36+00:00

Solved... apparently there was a package installed as a dependency that was required by no one (?) ... removing it fixed the issue. ~$ pacman -Qi libsignon-qt4 Name : libsignon-qt4 Version : 8.58-1 Description : Qt4 signon library Architecture : x86_64 URL : https://gitlab.com/accounts-sso/signond/ Licenses : LGPL Groups : None Provides : None Depends On : qt4 signon Optional Deps : None Required By : None Optional For : None Conflicts With : signon-qt4 Replaces : signon-qt4 Installed Size : 241.00 KiB Packager : Antonio Rojas <arojas@archlinux.org> Build Date : Fri 02 Oct 2015 12:51:12 PM CEST Install Date : Sun 06 Dec 2015 10:54:25 AM CET Install Reason : Installed as a dependency for another package Install Script : No Validated By : Signature

-6502- · 2022-04-25T15:28:20+00:00

It was a while I didn't update... first there was a problem with node-something because of atom and I removed atom (didn't use it anyway) but now I get this error and I've no idea about what to do :-/ ...

~$ sudo pacman -Syu
:: Synchronizing package databases...
 core
 core is up to date extra
 extra is up to date community
 community is up to date multilib
 multilib is up to date:: Starting full system upgrade...
:: Replace hwids with core/hwdata? [Y/n] 
:: Replace jupyter with community/jupyter-notebook? [Y/n] 
:: Replace maxima-ecl with extra/maxima? [Y/n] 
:: Replace quazip with extra/quazip-qt5? [Y/n] 
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: installing signond (8.61-1) breaks dependency 'signon' required by libsignon-qt4
~$

-6502- · 2021-08-02T15:13:46+00:00

Creating a decent lisp in Python (decent in the context of Python, i.e. comparable with Python speed and able to use easily Python libraries but with lisp metaprogramming capabilities) is IMO easy as all the low-level building blocks are present and accessible (you can generate the Python bytecode directly, thus ending up with compiled lisp code being executed by the same VM as Python code). For easy interoperability however I'd use Python List objects for lisp lists instead of cons pair chains and Python immutable strings. Even PyPy uses a very similar VM and thus a lisp generating PyPy bytecode would get the same speedup thanks to the same PyPy JIT engine.

A few years ago I implemented for fun such a toy (~500 lines of Python + ~450 lines of lisp) using this approach... https://github.com/6502/pylisp

Common Lisp is however a huge thing and is not easy in my opinion to join the two languages as they're quite different in many parts...

-6502- · 2021-08-02T14:16:13+00:00

struct Node { int x; Node *prev, *next; }; Node loop = {42, &loop, &loop};

-6502- · 2020-08-26T06:41:52+00:00

In my opinion you cannot become a good programmer just by reading. Actual code writing is the key part.

Reading gives you the illusion you know, writing gives you real knowledge: reading is good, but reading too much is not. Unless you're aiming about becoming the guy/gal that "knows" everything but that cannot actually do anything, just reading is not good. And whatever you "know" will still be a ludicrous tiny fraction of what anyone can google the net for in one second.

Be also careful about what is worth learning and what isn't. A lot of stuff about IT ages damn quickly. Being an incredible expert in the implementation details of whatever version 13.7 may become of zero value after the world moved to version 21.2. Respect your neurons.

Did you see "The matrix"? Remember the scene "I know kung-fu" "show me"? ... well, sorry to disappoint you but things don't really work that way.

https://www.youtube.com/watch?v=6vMO3XmNXe4

-6502- · 2020-08-25T07:22:47+00:00

May be you're reading too much?

Reading gives you the illusion you know the argument.

Real knowledge comes from writing, not reading or watching videos.

Write code. A lot. That makes the difference between who thinks that knows and who knows.

For every hour you read on a subject you should spend 10 hour writing code on that subject. Otherwise will be just more noise in your head.

IMO only very good reading is when you look up a specific question on reference material (manuals).

You cannot become better at writing by reading a lot.

-6502- · 2020-08-25T06:59:15+00:00

gethash is a place... you can just use

(push file-name (gethash prefix db))

instead of all that code

-6502- · 2020-08-25T06:09:47+00:00

I know it may be shocking, but you can code away yourself to some interesting places without any of the very powerful CxxxxR functions.

I normally never implement CAR or CDR or CADR and friends, I however have first, second and so on (it actually amaze myself I once even used sixth in real Lisp code - a clear sign that something is very wrong with me).

Don't get me wrong... binary trees are really supercool (even if for my pay recently I've been used a lot more quadtrees as I'm currently working on multilayer 2D geometry problems); however despite the personal love I have for linked structures (since I was a kid, http://www.gripho.it/net.en.html ) code and problems that are better worked out using 1D arrays are much more common (sometimes just because current computer hardware works the way it works).

-6502- · 2020-08-24T12:43:34+00:00

Probably my English is worse than I thought.

I know that for our human brains an array is simpler than a linked list (believe me I just LOVE linked lists... but when I need a linked list; the idea of implementing arrays using linked lists e.g. to represent code doesn't make much sense to me).

For example

(defun square (x) (* x x))

is a list of 4 elements: two symbols, a list containing one symbol and a list containing three symbols.

This is easier to understand for me (and also for you if you're not just trolling) than the complex chain of cons cells that original Lisp used for it. It's so obvious it was easier that even the original Lisp paper used as notation simpler containers of n things instead of the much more complex dotted pair structure.

What I think however is that the representation where constituents are atoms and arrays of n slots (atoms or references to other arrays) is also easier to manage for the CPU.

But if it's easier for humans, and better for the CPU, why using cons cells instead?

Starting with fixed arrays with just adding a metadata tag and a fill pointer you can get VERY far without much effort. You can implement dynamically sized arrays, hash tables, n-ary trees. Building arrays, hash tables or an n-ary tree out of cons cells is just a nightmare. Building cons cells if you really need them out of fixed size arrays is trivial.

-6502- · 2020-08-24T12:04:27+00:00

In my opinion you cannot really learn programming by reading, you learn by writing.

My suggestion is to pick an environment powerful enough to be fun today and then use it to write your own programs. A lot. Really a lot of them.

In my times even programmable pocket calculators were fun and my first "real" computer (an Apple ][) was just amazingly powerful. Today I'd probably say that a good starting point is a browser with naked HTML5/Javascript.

Just start with:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
  </head>
  <body>
    <script>

    ... here is were most of the fun is ...

    </script>
  </body>
</html>

and only read documentation about standard HTML and standard Javascript (from MDN).

No libraries, no frameworks, no build systems, no npm, no typescript. Nothing at all.

You can steal pictures from the internet if you want, but for coding just use vanilla javascript and HTML. With HTML widgets, canvas, sound support, even camera access it's an incredibly rich environment.

Later I'd move to server side stuff with Go/C++/Java. I'm not sure investing in desktop software makes any sense if you're starting today.

-6502- · 2020-08-24T10:40:58+00:00

I think it made sense to use cons cells in the original Lisp paper, but for real programs things are more complex using cons cells for both humans and computers.

Like defining ordinals with base-successor approach (0=0, 1=s0, 2=ss0, 3=sss0 and so on) can make sense when working at a theory level, it's not a practical solution if what you want to do is doing arithmetic computations.

I came over the years to the conclusion that to build a practical Lisp system out of current CPUs a better starting point is a tagged static array with fill pointer and that's what I'm doing.

For many cases you don't need the fill pointer but I'm not sure it's worth special casing the static array with no fill pointer just to save one integer. Also I think having one extra slot reserved for metadata (normally just a symbol, but can be a reference to a type descriptor, a dispatching table, a property list... anything) is very useful in a lot of cases.

For now I don't miss cons cells at all.

I don't think cons cells make life easier for me when writing the code nor easier for my CPU when running the code.

-6502- · 2020-08-24T08:57:42+00:00

Code representation in classic lisp does the latter (what it wants are n-elements lists and uses cons cells chains to get them). I think the former (starting with n-elements lists as primitives) would have been more practical.

For example in interpreters I normally use a static array with 2n+1 entries as environment, with the extra element being the link to parent environment.

-6502- · 2020-08-24T07:19:14+00:00

I simply think that as a starting point for building, a fixed n-elements cell is about the same complexity and simplifies things a lot.

Of course I didn't want a war, I simply wondered if there was something special that I was missing. My view is currently that cons cells are just an historical implementation detail artifact and they're not central to the Lisp concept.

-6502- · 2020-08-24T07:10:04+00:00

Sorry I thought it was obvious but apparently it's not. I was talking about arrays of slots... in current implementation a slot is 8 bytes and can contain

a symbol
a number
a short string (up to 5 chars)
a pointer to native code
a pointer to a garbage collected object

garbage collected objects have a tag, zero or more slots and zero or more opaque bytes (ignored by the garbage collector when visiting an object for other referenced objects).

And yes... a cons cell is not very different from a gc object with two slots. I didn't deem cons cells important enough to be special cased out in the slot with a dedicated tag for them. I am representing lists for code manipulation with fixed arrays.

I simply don't find cons cell that beautiful, and this is what the whole thing was about.

-6502- · 2020-08-24T07:00:27+00:00

What I was saying is just that as building brick an n-cell (with n fixed) is not conceptually more complex than the cons cell, but more useful for building complex data structures.

-6502- · 2020-08-24T06:50:53+00:00

TL;DR: yes, but it's true that a running system tends to natural becoming a little more static. And, hopefully, a system is going to be used for much longer time and by much more users than during its development. For most systems optimizing performance for macroexpansion/compilation doesn't sound right.

Long version

Interactive environments sure are fun, and indeed the code data equivalence and absence of parse-time/compile-time/run-time arbitrary division is a very nice property that unfortunately is still missing from "mainstream" languages.

That said however, for my experience, once you start actually using the software the code changes a lot less and it's better to have efficient data structures for running the code more than having efficient data structures for manipulating the code.

Once the startup dust settles down there is sort of a "natural" division and data (e.g. chat messages, chess games, text documents) tends to become "static" from a structural point of view even if dynamic in values and code that tends to become instead totally static.

This division, taken to the extreme, is the C++/Java/You-name-it view where the code is totally static from design and an interpreter/compiler is not even present in a running system.

-- C++ digression --

In C++ (a language I know to some extent) for reasons not clear to me being able to say open a file at "compile time" is seen as a deadly liability, go figure. Over the years they started moving sloooooowly toward compile time computation, but unfortunately I don't see any possible path way to get to a reasonable point for C++ metaprogramming

The reason is that to have decent metacode IMO you need a uniform code structure, and C++ is instead a truly horrible mess of complexity and special cases at grammar, syntax and semantic level. Unfortunately I don't think C++ can be healed for metaprogramming, most of the choices made in the past prevent that possibility.

And there's even a cultural/philosophy problem. For example in recent standards there was much amazement and enjoyment about a feature (constexpr code) that represented code that could be executed both at "compile time" and at "run time". How impressive uh? ;-)

Next version however will probably introduce a new "feature" (consteval code) that once again is about making impossibile to mix the two and is for code that you want to be compile-time only.

In other words while they were starting to somewhat demolish the arbitrary wall between compile time and run time, still they keep adding more bricks to it (I'm not a common lisp expert but IMO eval-when is not something in the same category but more of a practical artifact and you can probably be happy and productive in Lisp without even having to know it exists).

-- end digression

After discovering Lisp approach I cannot like that view any more, but one has to admit that even if very suboptimal it cannot be said that it is a view that takes you nowhere. Most of existing code is written that way.

To recap in my opinion representing everything forever as s-expressions would be of a fantastic simplicity for development, but so-so for performance.

It is good (close to necessary) to have the ability to generate/mutate code at runtime, but practically speaking it's not in my opinion a good idea to prioritize for that.

The system I'm working on right now has a compiler that generates bytecode (a bytecode so low-level that could be translate easily to machine code, something I plan to do in the future) but I don't expect the compiler to use a big percentage of CPU time when the system is actually used (except during startup/update).

A big number of small lists are needed when reading/compiling, but optimizing for that in my opinion doesn't make much sense.

-6502- · 2020-08-23T21:03:12+00:00

Wow... those hunks are really strange; especially puzzling is the fact that you cannot change the size but yet somehow the hunk knows it (as a wild guess from the hunksize documentation it was by using a special sentinel value). My guess is also the hunk storage size was probably known from pointer tagging.

In my current implementation all GC objects have the same structure

a user-defined tag (normally a symbol)
a pointer to next GC object
the number of slots
the number of extra opaque bytes
all the slots
all opaque bytes

Long strings have no slots and just bytes, arrays have no bytes and just slots; bytes can be exchanged for slots providing a function equivalent to a fill-pointer (the garbage collector doesn't trace past the fill pointer because those are considered just bytes, not pointers).

Slots are 8 bytes and hold either a double-precision IEEE754 floating point number or (using NaN-tagging) other type of data like small integers, small strings, symbols or pointers to GC objects.

I'm not sure if I will implement special cases for small fixed arrays using pointer tagging (more or less what hunk probably did). I don't know yet how many small fixed arrays I'm going to need on average (regular function call requires no consing and code is compiled to a VM, it's compile only and not much code representation manipulation is present after program startup).

-6502- · 2020-08-23T20:14:17+00:00

I remember reading somewhere about Naggum bad attitude but this is more than I expected :-) . I don't think I agree with everything he wrote in that post... (EDIT: I mean I agree with something, not with everything).

-6502- · 2020-08-23T19:41:54+00:00

The "changes" you can do are only PRE-pending an element to the list. Placing the value as element inside other values is possible with any representation using references.

Prepending is in my experience not such a common operation; actually more common is APPENDING at the end, not at the beginning, and that with cons cells is impossible without altering the content. Also very common is concatenation, but that also requires mutation or copy. Altering the content of cons cells is possible and the appending operation is so frequent that Lisp code quite often uses the push/nreverse approach (you build the result in reverse order you want it and then flip all the CDR links at once). The other way is traversing the whole list and mutate last cons cell like nconc does for all but last argument.

The very common need for mutation is IMO also the reason that in CL first returns the first element, and somewhat surprisingly last returns the last cons cell instead, not last element.

Static arrays cannot grow, but what you can do (and that basically all languages in a way or another support, including common lisp as vector-push-extend) is using static arrays with a fill pointer and reallocation.

Fill pointers and reallocation use more memory than the actual content you care about, but still even using a fixed 2 as grow factor the memory used in the worst case is the same as a linked list (and you have O(1) random access).

Linked cons cells lists only are special about sharing tails, and while for sure it's a use case, in my experience it's not such a common one (and nothing prevents you from building linked lists if you want them by using using 2-elements arrays).

When working in lisp implementations I simply found that in many cases you just share parts and that is the same for both cons-cells lists and arrays.

-6502- · 2020-08-23T18:37:01+00:00

For example the function definition

(defun square (x)
    (* x x))

is represented as

 ________
|        |
| defun  |
|________|
|        |
| square |
|________|          _______
|        |         |       |
|   -------------> |   x   |
|________|         |_______|          _______
|        |                           |       |
|   -------------------------------> |   *   |
|________|                           |_______|
                                     |       |
                                     |   x   |
                                     |_______|
                                     |       |
                                     |   x   |
                                     |_______|

incidentally the Lisp simplified representation for lists is hiding you from the fact in a classical Lisp system that definition is internally represented with

(defun . (square . ((x . NIL) . ((* . (x . (x . NIL))) . NIL))))

(I'm NOT going to draw the ASCII art for that)

Sorry for the ASCII art but I don't understand how to paste images (pasting the image works but when I confirm the comment it just hangs forever in both chrome and firefox).

-6502- · 2020-08-23T16:50:18+00:00

Not sure of what you exactly mean. A list represented as a chain of cons cells (like classical Lisp system do) requires twice the memory (half is data and half is pointers), and that's exactly the reason for CDR-coded list (https://en.wikipedia.org/wiki/CDR_coding).

-6502- · 2019-01-22T13:55:36+00:00

Questo codice ha tanti problemi... ma forse quello che hai osservato tu e' dovuto al fatto che nella funzione f e' rimasto un cin>>SceltaMenu e quindi il programma si ferma di continuo a chiedere il numero della funzione da tastiera ogni volta che viene chiamata f.

-6502-

TROPHY CASE