I obsessed a bit with the Burning Ship Fractal, and managed to get this beauty: http://i.imgur.com/E3kfD0R.jpg (colorized: http://imgur.com/a/B8XG1). Pretty cool for a wall poster if you ask me, I generated a bunch of sections of this fractal, going to build a mural sometime :)
Was skimming this Lisp Machine manual and fantasizing about making up some lisp-processor-like emulator. Does anybody have resources on the assembly language used by Lisp Machines (check chapter 27, page 432 of pdf) or the Ivory processors? I cant find a full reference online.
Just thinking of giving mezzano (operating system implemented with Common Lisp) a try, has anyone played with it?
I think I gave it a spin last year. It took a little bit of work to get running in VirtualBox, and I seem to remember there wasn’t much to do besides hack on lisp and hang out on IRC inside the OS.
Agreed. That is incredibly impressive. Long ago, I studied and extended a detailed (if inaccurate) tectonic simulation that someone else had written out of frustration with fractal-based continent outline generation… what I’d have hoped to get out of it was coastlines that have clearly developed from natural processes, and it never delivered anything remotely like that.
The river and erosion algorithms used here must have been a lot of work for the inventor, and I had no idea there was anything so good being done.
The part that renders it as line art so it feels like a map is also really cool, and I think does a lot to impress people even though it’s “just” presentation.
Just released a stockfish (chess engine) fork that’s scriptable using Lua. The point is to try to give a more “human” feel to the sort of errors committed when trying to damper the skill level, as the errors committed by the builtin skill level implementation are pretty silly. Some brushing is needed before showing off in chess forums and whatnot, but already does its work
AI seem terrible to learn against, for that reason.
What I really want is an AI game partner that I can have a retrospective with after the game is finished - “I messed up here; this was a bad move”.
As-is there’s no good way to learn what worked.
With some engines, you can at least get a rough idea from the numeric score that the engine outputs, which is the same overall prediction it uses to pick moves. I often play Chess on lichess.org and enjoy looking through the graph afterward.
It’s not the same as conversing with a human about it, and not all games are equally amenable to that sort of thing. But it’s something.
Hopefully I’ll find the time to play with blender, or more elisp, or some sbcl + sdl2. Or maybe procrastinate to next week.
I’m considering learning by Guile by rewriting my Vala program. I want to learn a lisp dialect language and I guess I don’t have any attachment to Guile but it seemed the most convenient given my intended project.
If you want to embed Guile in a C/C++ application and have any questions, I’ll be happy to help. I’ve managed to make it work (maybe not in the best of ways …) in a C++ multi threaded application https://github.com/rjmacready/Stockfish/tree/master, just check these 2 commits here and here, There’s still a lot of work to be done scripting-wise, but the boilerplate to call scheme from c++ and vice-versa is working.
That wasn’t part of my original plan, but now that you mention it, it might be! Thanks for the offer!
What are you planning on doing with it? I’ve been using Guile for a project and its been nice to work with.
So what would guile be used for there? User scripting of calculations? It’s hard to tell from the Readme / site. You mention rewriting stuff that’s in Vala, would you be building the UI in guile?
I hadn’t made it that far into the process. My initial thought was to attempt to move “LibBalistica” to Guile then just integrate that in instead of the existing Vala code.
Edit: The code for libbalistica is already compiled separately and statically linked within CMake, so if I were only going to do part of the project up front, it would be this or the GUI.
Hello all!
I’m still working in Rust as I have been for the last month. This has been a lot of fun and I’ve been learning a lot.
I haven’t poked at the command parser as much in the last week in any public sense. I’ve done a lot of experimentation with ownership and stuff behind the scenes, but nothing that I’ve wanted to push out. A big thing to sort out here is how to handle building the actual command tree without having to use RefCell hopefully. (But maybe I should actually be using RefCell…?)
I also started a new crate for doing ICU style message formats: https://crates.io/crates/message-format and https://github.com/endoli/message-format.rs … This has a good bit of work to do as I have to sort out how to actually do the argument handling as well as write parsing code. I’d welcome any help here.
I’m poking at some other crates / libraries that I’ll need to write … but not much interesting to talk about there yet.
I also noticed that Franz released the CLIM2 source code for the Common Lisp Interface Manager. This is letting me answer a lot of questions about how some things were done in the official versions. It is also pretty cool to be reading through code with a 30 year history and not find it repulsive. :)
Also, if someone’s interested in learning Rust, I have a bunch of projects that I need to get working and I’d be happy to help mentor someone. Most of these things are even generally useful.
Franz released the CLIM2
This thing? https://github.com/franzinc/clim2
Oh, I have to take a few days to look at this :)
Regarding the parsing subject of last week, i found an interesting paper but i’m yet to read it.
I’ve finally started to play with emacs' elisp and org-mode, and i managed to use dynamic blocks to insert images generated by a project of mine that has a web endpoint http://i.imgur.com/KFhIezx.png. I was also able to implement a new type of hyperlink that just POSTs to my project and opens stuff in there. Next step is probably refreshable lists.
Thanks for the update, always keen to learn more about advanced parsing techniques.
I will add that paper to my reading pile.
Me too! I’ve been wondering what the state of the art is in extensible or bidirectional parsers. If anyone here knows anything about the subject, I’d love the extra reading material.
I was trying to look for resources on “real time file parsing”, but I don’t know the true terminology (I suspect there’s one! “incremental parsing” seems to be it, although i can’t find more formal stuff).
I wanted to know of the techniques that can be used to parse a file, hold the AST, and update the AST as the file is updated as well (content can be added, or removed, or inserted at the middle of the file). A poor man’s implementation could involve some filediff library (can libgit handle this?).
Are you familiar with the concept of a zipper?
Yeah, that explanation isn’t great. At its core, a zipper is a data structure for looking into and moving around another data structure. It essentially works by separating the “focus” (the part of the original data structure at which you are currently looking), and the “context” (the rest of the data structure).
As a simple example, if you have a list like [1, 2, 3, 4, 5, 6], the zipper of this list would look like [[2, 1], 3, [4, 5, 6]]. The single element (‘3’) is the “focus,” and the two lists (the first one reversed, for efficiency) are the “context.” You can then define functions to move this zipper to the left ([[1], 2 [3, 4, 5, 6]]) or the right ([3, 2, 1], 4, [5, 6]).
This notion of the zipper can be generalized to other data structure (a tree is a common example). In every case, the idea is how to efficiently walk through and view the innards of a particular data structure, particularly across repeated operations. If you want to operate on a segment of a tree, it’s easier to get a zipper of that tree with the focus on the desirable section, and then operate on that focus, than it is to repeatedly find the important part. In a functional context, the zipper facilitates this.
Huet’s original paper on this is quite good, I think.
Thanks! I’m glad it helped! I had similar issues understanding zippers when I first learned about them. I really think introducing them with lists is easier than introducing them with trees, which is what most tutorials I’ve found do.
That’s super and thanks a lot for the link to the orginal paper. When you say to move around another data structure, I suppose you mean without modifying the original one ? An I suppose it include create a copy modified of the data structure without modifying the original one
“incremental parsing” generally refers to the idea of your parser being able to wait for input and/or be given more input.
Say if you are writing a parser for c and your input so far has been
struct foo {
int a;
your parser can ‘halt’ and ‘wait for more input’ as it can clearly see this struct isn’t finished, this isn’t a complete program specification yet.
However, to the best of my knowledge, “incremental parsing” doesn’t include the ability to modify previously parsed things - that is it is only additive and doesn’t allow for removal or modification.
If you find a solution on this or a term to encapsulate it, please share, I would be very interested!
Incoming: command line utils should ship with spell-checkers, because they don’t exist to punish people for their spelling mistakes. This is annoying me more than it should, since I use no node.js at all :)
May I add developing an operating system? It got me entertained for 1 month 4 years ago, I followed this tutorial http://www.jamesmolloy.co.uk/tutorial_html/ although it seems to be down at the moment,
Not anything concrete, but I’ve been looking for excuses to use neural networks or machine learning in a chess context. Some use cases:
Any links / similar ideas / thoughts appreciated.
Not anything concrete, but I’ve been looking for excuses to use neural networks or machine learning in a chess context. Some use cases:
Using a db of games, try to group players with a similar “style” of playing.
Try to classify games as “interesting” or “not interesting”, definition of “interesting” to be defined :)
Using some sort of training, try to “learn” the sort of positions where someone is more error prone
More ideas appreciated
Any links / similar ideas / thoughts appreciated.
Is this related to ur/web?
Looking at the code, this seems to be heavily tied to windows? Is there anyone more familiar with this that can speak to the portability of Dolphin?
I’m not really familiar with it, but from what I’ve read yes, it seems tied to Windows only. There are cross platform smalltalks though, such as pharo. I can’t say for sure how hard would it be to port it to other platforms.
Go sucks, but I think his points about Scala are valid. Java-in-Scala is terrible and Haskell-in-Scala is terrible. Java-in-Scala programmers unwittingly circumvent the type system (e.g. passing null instead of None, meaning that you have to check for it anyway, and Haskell-in-Scala programmers end up using patterns that make sense in Haskell but become inelegant in Scala.
Implicits are also painful to debug, SBT is a nightmare, and the language feels like Magic: the Gathering where if you leave for a year and come back to it, there are all these new rules that have changed the game entirely. Then there are the slow build times.
I’m going to avoid saying too much about IDEs. If IDEs are seen as necessary rather than as an occasional nice-to-have, then you need to move upstream in your hiring. Sure, I’d probably use an IDE if I had to contend with a massive Java codebase, but they’re not integral to how I think about programming. Whenever people say they’re resistant to a new language because it lacks IDE support, I want to fucking scream.
All of that said, I don’t know that Go will solve his problems. Sure, it will prevent the chaos of overly clever Scala code, but everything Go lacks will be remade in multiple ways by different developers, Greenspun-style, and instead of contending with 2 different schools of design/development, there’ll likely be many more than just two in-house cultures around how to work around Go’s limitations.
Whenever people say they’re resistant to a new language because it lacks IDE support, I want to fucking scream.
Why so? I dont mind hacking C++ and scheme on emacs for leisure, but when you’re picking the tools to create a project, people want (need?) to be productive, and proper tools (read IDEs, usable debuggers, autocomplete, …) is a must-have, not a nice-to-have, for that. I don’t get the hate towards people who want proper tools :)
Implicits are also painful to debug, SBT is a nightmare, and the language feels like Magic: the Gathering where if you leave for a year and come back to it, there are all these new rules that have changed the game entirely. Then there are the slow build times.
The language has slowed down a lot in response to this kind of criticism. Five years ago was very different from three years ago, but I’d say it’s very much the same language it was two years ago.
SBT is awful. I don’t know why people use it. Just ignore it and use maven.
Implicit debugging is relatively well-supported in IntelliJ these days, or with -Xlog-implicits on the command line.
Build times are better than they were, though that’s always relative.
Implicit debugging is relatively well-supported in IntelliJ these days, or with -Xlog-implicits on the command line.
This is interesting to reflect on. A fairly common language feature requires an IDE or some compiler option in order to understand what is going on. Specifically: the code itself is difficult to understand without help.
I hope in a decade or two, features like this will be seen as a red mark on a language. IDE support, or not, being able to understand code just by reading it is an important feature, IMO.
Heh. I see it as just the opposite: it’s the first effective language that’s starting to make use of the power of modern UIs, even if only at the level of highlights and underlines. Mouseover gives an extra gradation between “displayed” and “not displayed” that’s perfect for certain kinds of operations that you want to be mostly hidden but not completely invisible. I really think anyone who talks about graphical/visual programming and moving beyond the text editor would do well to look at a modern Scala IDE, and see how a restrained use of graphical elements can enhance the editing of program text rather than trying to replace text entirely.
My comment was that a language feature requires IDE and special tooling to understand what the code is doing. Your response doesn’t make sense to me, though. One can build similar tooling for any language, is Scala better because it requires such tooling? In what way would we be worse off by making that information local such that tooling is not required to understand a program?
In most languages you have to make a function explicit or completely invisible. E.g. I’ve worked on projects that used async in Python and you either made the yield points explicit or you had them sliced out invisibly. Either approach was clunky. With that particular example they solved it with language changes but that’s not a sustainable approach - you can’t do that for business domain cases.
I think it’s pretty common to have a business object that’s almost-but-not-quite another object - it’s maybe not 100% Liskov substitutable but it’s not different enough that business users think there even is a conversion process between them. (The specific example I’m thinking of is an underwriting stamp as a layer of a reinsurance contract, but the point is these are domain-specific things). We see a variety of approaches to these kind of problems - decorators in Python, annotations with AOP in Java, macros in a number of languages. IME all of these would be better off displayed as implicits (and we do see a little of that e.g. some IDEs have native support for Spring annotations, and will hide the annotation and highlight the field instead. Compare also IntelliJ’s “folding” of Java-pre-8 lambdas).
Making that information explicit in the text would make the program too verbose. While implicits can certainly be misused, they’re more often used for conversions that would be completely invisible in a text-only programming language.
I’ve never been bitten by code being explicit. I’ve been hurt by code being verbose, but that is different than explicit. For example, in Ocaml, making the import of a symbol as close to the usage of the symbol is easy and readable. One can even import a module just for a single expression.
On the other hand, I have been bitten countless times by things happening implicitly. Some weird behaviour happens because I did something not realizing there was implicit behaviour that invalidated an assumption. Or spending a long time trying to determine why something was happening because of some implicit behaviour.
So, while I can understand your perspective, it’s one I cannot relate to at all. We’re all a product of our experiences, I guess.
If by implicit you mean not visible when working on the code with the normal tools for doing so then I agree. But I think Scala makes that space smaller, not larger, because the implicits let you make things visible that would make the code too verbose if you had to write them in text. The language culture (as I’ve experienced it) is all about using small wrapper types to track small distinctions, and lifting concerns like “audit event” or “needs to happen in a database transaction” or “performs I/O” to be handled by the type system, possibly implicitly. It’s wonderful to be able to pass a concern like that all the way up to the routing layer in Spray, and know that it can handle it (via the implicitly resolved marshaller for that type) because you’d get a compile-time error if it didn’t - whereas that’s at best a runtime error and sometimes not even that in every other web framework I’ve seen. And the only thing that makes that practical is that the marshaller doesn’t have to be explicit in the route definition.
SBT is awful. I don’t know why people use it. Just ignore it and use maven.
Once I’m at “use maven”, I’m at “use another language”.
I had hoped that SBT would improve. I remember it being a recognized pain point as far back as 2011. Then again, almost no one likes their build tools.
I think most people are pretty happy with SBT. All build tools suck, but SBT is one that sucks a lot less than others. You have to imagine that the bad parts of SBT are still magnitudes better than the good parts of the tools in Haskell, Go etc.
almost no one likes their build tools.
Shrug. I love maven. I’ve even used it to build Python when I had to write that.
I’m using HttpClient and at the beginning I assumed that the proper way of usage was to keep a single instance in the application (since I needed a “web session” anyways, with cookies and all), happy to check I “accidentally” used this correctly :)