robert-zaremba

what's wrong with elisp? The runtime is really well integrated in Emacs! Note: AI is good at writing all lips dialects!

In my 20 years living inside Emacs, the running joke has always been that it's a great operating system lacking only a good text editor. With Neomacs bringing a GPU-accelerated display engine, and WebKit to the table... it looks like our operating system finally got a modern compositor. On top of that multithreading! (so some cache ops won't pause the editor!)

Jokes aside, this is exactly the kind of mad-science evolution Emacs needs, rather than being hard-blocked by 1980s terminal-era C code.

I'm curious how much of this project is done by AI? PS: kudos for doing it, I will definitely support it!

Go is my the most favourite language, so I'm happy to see a Go based editor. However this days I'm writing code mainly in typescript (for Cloudflare workers). TS is the most popular language and you guys will definitely need to prioritize TS.

The strategic move to use TPU rather than Nvidia is paying well for Google. They are able to better utilize their existing large infrastructure, but also specialize the processes and pipelines for their own framework that they use to create and train models.

I think a specialized hardware for training models is the next big wave in China.

During my university time, I used to do a lot of different programming puzzles and algo. I think it an invaluable training that every serious engineer should try without relaying on AI.

Skills are trained by practice and thinking. Skilled people will never be subsidized by AI. Unskilled juniors, who don't train properly will go into tranches (as it's already happening).

It's based on X11, unfortunately. I've fully transitioned to Wayland based desktops I would be very happy to try FyneDesk if it would be based on Wayland.

I see they work on full Wayland support, and targeting to do it in v5.0. What's the ETA? Last release was 1.5 year ago!

> The 0.4 branch of releases marks the end of X11 native implementations as we will begin the move to Wayland (and XWayland) for 0.5. > https://github.com/FyshOS/fynedesk/releases

KAT-Dev-32B and KAT-Coder are optimized via several stages of training, including a mid-training stage, supervised fine-tuning (SFT) & reinforcement fine-tuning (RFT) stage and an large-scale agentic reinforcement learning (RL) stage.

TBH, I'm sick about LaTeX: - compilation is heavy - it's not friendly for writing (far from the dominant markup languages) - poor support to HTML / Epub / mobile outputs - output (PDF) not friendly for parsing / digesting. - tonnes of templates, lot of mess.

We should just use human friendly markups like MyST Markdown [1] or Org Mode [2].

Unfortunately, whitepapers are predominantly written in LaTeX. Thankfully, arXiv recently made a move to parse and render those documents in the web format. It's a hard job. But this is the wrong way around: instead of keep composing documents in LaTeX (which is not human friendly), and then doing the hard job with tooling, we should start with human first approach and have win-win!

We are living in the world where web content is the primary content and friendly for desktop, mobile devices and readers and tools (select, copy, edit...). It's easy to package any web content into epub and ship it in a single file. Printing is also easy. Only cons: precise typesetting is not harder. But this is less of the problem. I would prefer a content that is friendly to read and is responsive, than a precise typesetting.

[1] https://mystmd.org/ [2] https://orgmode.org/manual/Summary.html [3] https://info.arxiv.org/about/accessible_HTML.html

Thanks for a comment. What's the reason for not posting own article to content discovery services / agregators? It's a common thing.

I hope one day all popular browsers will render EPUB straight away. Should be lot easier then PDF.

Majority of publications are simple text with few tables or diagrams. We don't need complex typesetting for that. Printing from EPUB should be good.

You always need an extra app to view PDF. It's either installed by default or not. Phones, tablets, and other screen devices have available EPUB, MOBI, HTML browsers to install.

there are plugins for that (same as you have with PDFs, though you reuse same rwndering engine, since EPUBs are html documents under the hood)

yes, screen size.

Most of the people will agree with me that straining your eyes is not a good solution ;) Little letters are not comfortable neither healthy.

Good point! Sorry if my Call sounds repulsive. Your idea with creating publications in multiple format works. I will update my post for that. Though, in my post, I want to highlight that usually simple solutions works fine. Most of this publications are not complex in terms of typesetting. If there is an objective for complex typesetting than fair enough.

Reading PDF on mobile is possible, but far less comfortable than EPUB / MOBI...

EPUB / MOBI reader is not a problem this days

That's where EPUB / MOBI comes for.

that's the thing. 1) If you use simple HTML / EPUB majority of publications are good for printing. 2) Think about a relief of storing this documents on an ebook reader

Do you publish on the Internet? Do you read a lot of publications on your digital devices?

How about stopping using PDF for internet publications and using EPUB instead (or some other screen independent format)? Please, share your comments.

Awesome! Hope sooner then later we will see better PyPy adoption. When do you expect working on CPython3 C-API compatibility?

The same goes for Torch: New York, Oxford ...

We don't need to shard our data, but we do multiple node setup for HA using Pgpool + streaming replication.

From what I heard sharding my be really problematic, and one should avoid it as much as possible.

PostgreSQL support that through triggers and Notify (www.postgresql.org/docs/9.4/static/sql-notify.html). You may look into chat example: https://gist.github.com/quiver/4240546

At AgFlow (http://www.agflow.com), we've been using RethingDB for 2 years (since version 1.3 to 2.0). Eventually we migrated to PostgreSQL. The query language from RethinkDB is very powerful. But it's nothing compared to SQL when it goes to expressiveness and performance (at least on PostgreSQL). ReQL is deceptive. It performs well as long as you don't embed JavaScript or don't do sophisticated joins (even based on indexes). When doing more complicated queries it becomes very ugly and slow.

Our main motivations for migration was:

    * transactions
    * performance  
    * tool kits around SQL  

We are very happy after migration. Backup process is way faster. I think there is only one place where RethinkDB is better then PostgreSQL: replication + automatic failover. If your data is not in TB, then I wouldn't recommend Rethinkdb. World with relational DB, transactions, pl/sql, pub/sub, GiS, data constrains, stability... offered by PostgreSQL is way easier, reliable and offers better performance.

Unfortunately lua still waits for a great adoption in ML communities. By now, ML is dominated by python, julia and matlab.I think lua (especially by LuaJIT) is a really strong player in this ground with a great libraries and research projects. I'm waiting for some lua data mining oriented conferences.

I'm successfully using PyPy in production. It's about data processing. The most important dependencies: redis driver, beautiful soup.

             PyPy   cPython
  jobs/sec    ~60      ~8  
  mem usage   1.5G     2G

When using lxml on cPython, the jobs/sec increased to 10 (on that time lxml wasn't supported by PyPy, now it is). I really encourage to give a try to PyPy.

Bitbucket doesn't check the permissions first before suggesting them as a reviewer to the repo.

This can be really annoying when in your company you make all tasks resolution through bitbucket pull request.

Interesting thing is that when using geenlet + proper event framework (gevent / eventlet) you don't have all this issues about different callback styles / methods / objects, and what is more important, IO libraries support (like DB drivers). I know there are ways to use twisted drivers in tornado, or use `deferToThread` - but they doesn't seems as pythonic as monkey patching + python drivers (like with eventlet + <your pure python DB driver>)

It's worth nothing that PyPy has a great support for greenlets with his JIT.

The PyPy platform is really amazing. I hope one day the we can use all the scientist Python libs on PyPy! cffi (http://cffi.readthedocs.org/) makes writing FFI much easier and in more portable way then using python CAPI or clunky ctypes. And now the STM - a remedy for the famous GIL.

Right now there are much useful issues then MS Windows support ;)