acqq

Indeed

https://huggingface.co/SparseLLM/ReluFalcon-40B

"We utilize PowerInfer for inference"

"the language the scripts are written in is called Nombas ScriptEase 5.00e."

https://brent-noorda.com/nombas/us/index.htm

"Nombas doesn't exist any more. All the good stuff was sold to Openwave, then sold to someone else, then sold to someone else, then I lost track."

> The main advantage is that cross-compilation to many targets is supported out of the box

For the readers who aren't familiar:

The code for running test and then cross-compiling (on one machine and OS) for different target platforms is:

https://github.com/jedisct1/libaegis/blob/main/.github/workf...

and the only zig file in the repo which drives the build process is:

https://github.com/jedisct1/libaegis/blob/main/build.zig

Here a paper can be found about running the "cards" created by Rainer Glaschick based on the program described in Lady Lovelace's Note G on a modified emulator of the Babbage's analytical engine:

https://rclab.de/analyticalengine/lovelace_noteg_paper

And the text by the author of that emulator about the authenticity of the emulator:

https://www.fourmilab.ch/babbage/authentic.html

Note that the sizes of what we would today call "registers" in what we would today call "ALU" were, per 1837 description 40, per 1864 description 50 decimal digits, much bigger than the number of mantissa decimals in common "float" (7) or "double" (15) floating point representations, and the assumption of the engine was to use fixed point decimal arithmetic.

AFAIK: you also link to a different (lower!) glibc version from the one on which you do the compilation, probably solving the problem you had without having an excuse that you linked an "untested" library.

To be clearer to those who don't read what's linked but reflexively downvote:

zig is not only the language, it's also a build system that compiles C (also in Go CGO use scenarios) better than the default C compilers, allowing order of magnitude easier cross compilation. It's described in the link I've already provided exactly by compiling SqLite for its use in Go!

Is this something inherent in CGO implementation? If your dependency happened because the compiled library depended on it, do you know that that is probably avoidable (I haven't tried your use case, so I could be wrong) by using zig as a compiler as it can "cross compile" for lower glibc version and also to musl, avoiding glibc altogether?

I would need to read more about that to understand how it could be a problem. You see, I've literally spend decades using C and I can never imagine how adding that what I understand to be huge dependencies like wazero.io and executing huge wasms binaries made from original C sources can be more debuggable than debugging a directly compiled native code -- I'm just disclosing my bias, and I want to be clear about it, I'm certainly not doubting your "better experience."

Edit: have you tried that zig workflow for cross-compiling?

Edit2: and I'm also aware that zig also uses wasm binary and its own wasm2c, written from scratch, for its own bootstrapping:

https://ziglang.org/news/goodbye-cpp/

Independently of that article, I've experimented with webp to find out when I would use it, and concluded approximately the following (of course, somebody else can have different preferences and conclusions):

- If you know how stills from mp4 videos or similar "look like" (when observed so that the compression artifacts are visible) -- that's more-or-less lossy webp. Not something you'd expect to achieve the best picture quality.

- Probably because of its origins, that's also how lossy webp handles scanned or printed images: not good.

I've concluded that I will use webp, but

1) to save the pictures for which I don't care which quality they have, and if I want to use up less bytes: specifically: if I want to save some visual information from some JPEG from somewhere only to store a picture of that not to preserve it in its full quality.

2) when serving the pictures, in scenarios where I want to reduce the amount of data delivered to others, when the artifacts I'm aware of aren't the issue.

Everything else: still no.

Moreover, if it's about cross-compilation, why not using zig?

https://zig.news/kristoff/building-sqlite-with-cgo-for-every...

Many thanks for this good answer, that level of detail is exactly what I have been missing up to now.

I'm surely aware of the fact that C cross-compilation is often very clumsy implemented. But I also have to mention that there is a project that also tries to solve that too, while also creating a whole new language:

https://zig.news/kristoff/building-sqlite-with-cgo-for-every...

I'm still missing some details to understand that story, as I don't believe that there is any platform that Go supports on which C sqlite would not run, more the opposite, the memory requirements of wazero.io way must be clearly higher than of the C sqlite library?

It seems to me it's not about would C sqlite run or not on that platform but that there is still some other convenience, and that's what I'd still like to learn, as I'm sure ncruces does solve some specific problem.

I'd like to read what the actual benefits of not linking to C sqlite implementation are. I can imagine using wazero.io for libraries, but I fail to understand _why_ would anybody prefer to run sqlite that way from their own go program, except if it's in cases where execution times are clearly not important (which explains to me the background story).

Whoever types exit in REPL will never care what "repr(exit)" does.

Python has a lot excuses about the need to remain "consistent" but the reality isn't so:

    >>> x = open( "/tmp/whatever123", "w" )
    >>> close( x )
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    NameError: name 'close' is not defined. Did you mean: 'cosh'?
    ...    
    >>> x.close()
    >>>
    >>> x = "tttt"
    >>> x.len()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>    
    ...
    >>> len( x )
    4

I agree with that estimate, I think it was really the idea of Python to be less than "good" by design.

I mean one doesn't need more than:

    >>> exit
    Use exit() or Ctrl-D (i.e. EOF) to exit

to see. They have that special handling, but they still don't want to let you out, because... IMO, they just want to be annoying.

When a solution could be something like:

    Note: exit() is needed in scripts. In this prompt Ctrl-D (i.e. EOF) can also be used.
    Exiting.

"We think of the breakdown roughly as follows: of our roughly 30% original speedup, 10% is going into Pyston-lite, 10% was done independently by the CPython team between 3.8 and main, and the remaining 10% we are hoping to contribute back upstream."

To compare with Javascript: if I remember, as it appeared, V8 JIT was orders of magnitude faster, compared to the interpreted code.

The link is about the assembly details of the compiler code. But that still misses the point in a few important ways. And I'm not talking about the Turbo Pascals with the numbers 5 or higher, but about the first ones actually used, like the one for CP/M where the OS and the program all have to fit in 64 K. Turbo Pascal was more than a compiler fitting in that space: it contained editor, kept the source of the compiled program completely in RAM, and produced executable with one write to disk and just a few reads.

https://techtinkering.com/2013/03/05/turbo-pascal-a-great-ch...

1) The fact that the author was very used to think in assembly is that he was able to generate a compiler to the native code that even without optimizing passes already "well behaves": not squeezing every drop possible for optimization but also making a lot of optimization passes not necessary. That's the "magic sauce" in being what was called "a single pass."

2) Description "a single pass" is actually somewhat imprecise when used by most who talk about it. The passes through something are necessary in compilers, the actual goal is making once the processing on the levels which hurts the whole compilation process the most.

3) So the major difference between the typical "production" compilers and Turbo Pascal was in later being able to fit "everything" in the RAM between the last edit and the production of the compiled code. If I remember correctly it didn't even have to write anything to the disk if one just needed to run the program(!) Only when one needed the executable the write happened.

So assembly was an important part of the story but at the time most of the professionals used assembly anyway, the speed vas result every other decision was also made to achieve minimal I/O (which also wasn't necessarily unique feature) while also being useful enough for the real programs (that was less unique) and comfortable (Wordstar-keys editor, jump to the error after compilation).

A lot of very good decisions combined, that was special. And finally, comparably cheap, too.

Changing the code and seeing the results was even on the machines of that time practically immediate with the first versions of the Turbo Pascal, as long as the program and the source were able to fit in the RAM. And the interaction was designed to be immediate too. If I remember correctly the compilation error didn't cause infinite screens of report, it just repositioned me to the line where the error was. If the cause was a typo, I was able to edit recompile and run in a second. Most more recent tools have other ideas, requiring more unnecessary activities from a developer.

Actually, how was Turbo Pascal faster than the competition was completely obvious to those experienced in the software development at that time:

It did everything possible in memory, avoiding reading and writing of temporary files. Microsoft tools did it with the file I/O for multiple passes, a traditional solution for coping with limited RAM and applying optimization steps and targeting different processors.

AFAIK it was initially made to run on CP/M 8-bit systems, that 64 KB limit was a consequence.

I know I've used it on CP/M first.

It was really, really fast.

> due to it being superficially simple to learn

I, however, don't think most of the people who started using one of the named languages instead of their mother tongue ever really selected English using that specific criterion.

I like k2pdfopt for reformatting pdfs for my e-reader.

I've also used poppler's pdfimages but I'd prefer like something less buggy for my use case; any version I've tried had problem with one pdf made by Adobe InDesign.

Also, tesseract allows creation of a pdf from the images with the embedded OCR text. It is also built in in the k2pdfopt.

"Eric Idle denies collaborating with John Cleese on Life Of Brian stage show: ‘I have nothing to do with this’"

https://www.independent.co.uk/arts-entertainment/theatre-dan...

The physics and chemistry must work the same, the same limitations determine biochemistry too.

(2018)

> The fourth is Ta-Ra-Ra-Boom-De-Ay, an almost academic account of the music business from the early 18th century.

https://unbound.com/books/ta-ra-ra-boom-de-ay/

As much as 44 Chapters, where Chapter 1 starts in 1710 ("a law protecting an author’s rights in his written work – the Statute of Anne") and Chapter 2 is already 19th Century ("The Beginning Of Records")

For the reference: NextStep 3.3 screenshot

http://toastytech.com/guis/ns33nfsmanager.png

(3.0 released Sept 1992, 3.3 Feb 1995)

Windows 95 released Aug 1995.

> These good relations with USA did real good when their country was obliterated to shreds when it was no longer needed.

The US had these teachers:

"We have no eternal allies, and we have no perpetual enemies. Our interests are eternal and perpetual, and those interests it is our duty to follow."

https://www.oxfordreference.com/display/10.1093/acref/978019...

Always new counties which have to experience that.

Cold War Diplomacy - Defense Treaties of the United States

https://avalon.law.yale.edu/subject_menus/mutdef.asp

(in 1949-1951)

- 1949 - NATO Treaty; April 4

- 1951 - Defense of Greenland: Agreement Between the United States and the Kingdom of Denmark, April 27

- 1951 - Defense of Iceland: Agreement Between the United States and the Republic of Iceland, May 5

- 1951 - Mutual Defense Treaty Between the United States and the Republic of the Philippines; August 30

- 1951 - Security Treaty Between the United States, Australia, and New Zealand (ANZUS); September 1

- 1951 - Military Facilities in the Azores: Agreement Between Portugal and the United States, September 6

- 1951 - Security Treaty Between the United States and Japan; September 8

- 1951 - Military Assistance Agreement Between the United States and Yugoslavia, November 14

Indeed:

https://www.politico.com/story/2013/11/harry-truman-requests...

"The United States then began inching closer to Tito, supporting his regime rhetorically, economically and, finally, militarily, in order to ensure that Yugoslavia would remain out of the Soviet orbit. Throughout the Cold War, American officials saw in Tito a useful example of a communist leader who was not under the Kremlin’s thumb."

...

"With congressional assent, the United States and Yugoslavia signed a bilateral military agreement in November 1951 that tacitly incorporated Yugoslavia into NATO’s defensive web."