I installed rakudo and played with it a little. However, the repl was horrible. Is there a repl that accepts multiline subroutines and if possible readline support?
I think you may want to install the module called Linenoise. If you have panda (Perl 6 module installer), just type panda install Linenoise and you should be all set. https://github.com/hoelzro/p6-linenoise
The REPL is one of the features that hasn't gotten as much attention as it should. It was much more important to spend the time getting the rest of the language into shape.
That said I use the REPL for 90% of my coding. Including temporarily replacing parts of the runtime while trying to fix them.
I thought that way until I worked with iPython for a while (back when it was primarily a clever REPL, and didn't really have the "notebooks" feature at all, yet, I don't think...this was back when it was new). Having a really strong REPL when debugging is like having a rocket, when you're used to having a hot air balloon.
I've always been bothered by the weakness of Perl REPLs. It's only recently started to improve (in the past five years or so) for Perl 5, but there are some decent ones, though nothing even in the same league as iPython.
That looks really nice. And I like that it defaults to doing the right thing. I always have to read the docs when using gdb, as it happens so rarely that I forget the commands for doing things...and it definitely does not default to useful behaviors, certainly not just hitting "enter" to do the next obvious thing.
A debugger doesn't take the place of a good REPL, but it's a useful component of a good REPL.
There is a lot of shifting around on the #perl6 chat room in recent months to get Perl6 interacting with Jupyter aka the iPython notebook. Which means you'd probably be able to use iPython command line as a command line client, just without all the Python bells and whistles. If you're interested in seeing that through I'd make some noise in the chat room. Even just saying you'd want it will go a long way! Timotimo looks to be the person to hi5 as he already has some code https://github.com/timo/iperl6kernel
Competent Jupyter integration would be amazing. I haven't had reason to work seriously in Python in many years, but iPython is just fantastic, so having that kind of capability for Perl 6 would make Perl 6 even more attractive for me. I think a lot of folks just don't realize how cool it is, until they actually work with it for a while.
Not necessarily just from a debugging perspective (though I did mention debugging, specifically, above), but from an exploratory programming perspective. The ability to start with a snippet of something, and then trying new things. I often don't know how to solve something until I've tried several ways of doing it. A REPL (a really functional one like iPython, or, I imagine the better Lisp or Smalltalk REPLs, though I've rarely used either language) is a really nice way of doing that.
A debugger, in my mind, is for running the program as it exists on disk and then inspecting it. A REPL is for interactively writing a new program. It is a different way of thinking about programming. On one hand it's something you do first in your editor and then you fix the bugs in the debugger. On the other hand, it's something you tinker with until you're happy and then you commit it to disk. Even when I worked in Python, I would mostly write the code in vim, but when I was trying to understand a new library or sort out the right data structure or algorithm for something I'd use the REPL.
I guess the lines are blurry. iPython is called a Python shell, or was when I was using it. So, saying "REPL" may be misleading, if your vision of a REPL is merely "it executes a statement". You can build up quite complex functions in iPython and execute them on arbitrary data. It doesn't restrict you to one-liners.
If the Perl 6 debugger allows defining new functions (and other stuff beyond merely tweaking data), then it's probably in a similar category, if still immature.
I think there is simply a miscommunication happening here, where folks unfamiliar with iPython are assuming it is a simple REPL (like the Perl debugger in REPL mode. I'm not talking about a dumb thing that executes one line of code and returns. iPython (and, again, I imagine the better Lisp and SmallTalk REPLs) is a full shell with your programming environment available, including the ability to use the debugger interactively, explore your data structures, etc. But, you can also create new functions, modify existing ones, and it has command history, etc. All the stuff you'd expect of a good shell, but in Python and with a complete picture of your program's execution environment.
I've simply never felt like I was able to get inside of a program like when working with iPython, and I'm not at all a good Python programmer.
Thats pretty much the same things that I would do using an IDE and step through debugger. I find an IDE far more convinient to navigate, but maybe thats just familiarity.
In bash I use a few aliases (which load different libraries for DB and specific data structures) for perl -E
I have simple shell aliases to do SQL queries and pipe the output to shell aliases which transform that to perl data structures (along with some project specific data structures). And so on.
(The bash ctrl-R backward searches rarely interact between shell commands and searches for these one liners.)
Please stop shaking your head. :-)
I agree that the old lisps I used back at Uni was neater than this one liner craziness. I've thought of trying a REPL instead, but with one liners I can also use the bash functionality for processing files and so on.
I did a small experiment to see if st would actually be much snappier. Font rendering was a little worse but that was tolerable.
ST is fast (as expected)
$ time $(for i in `seq 1 100`; do st -e true &> /dev/null ; done)
real 0m5.493s
user 0m4.417s
sys 0m0.647s
URxvt is a little slower (but traditional wisdom should tell you that if it is actually so small that you need to measure it to perceive the difference, the difference probably doesn't matter)
$ time $(for i in `seq 1 100`; do urxvt -e true &> /dev/null ; done)
real 0m11.099s
user 0m9.780s
sys 0m0.853s
URxvt client (with a separately launched urxvtd) is faster than st.
$ time $(for i in `seq 1 100`; do urxvtc -e true &> /dev/null ; done)
real 0m4.593s
user 0m0.007s
sys 0m0.017s
Given how solid urxvt has been for me over the years, and given that I run urxvtc already, I don't see why switching to st would help (the argument against featuritis can obviously be made, but urxvt is fairly minimal as well).
Note: I do not know how it would affect it, but I also have a .Xdefaults that sets fonts, colors etc for URxvt.
Edit:
adding xterm to the comparison since some sibling comment mentioned it
$ time $(for i in `seq 1 100`; do xterm -e true &> /dev/null ; done)
real 0m8.525s
user 0m2.777s
sys 0m0.770s
I wasn't talking about startup speed as that can be ignored given the kind of shells and configs we use these days which will consume most of the start time.
What I was talking about were things like how much memory overhead the emulator has and how fast it paints stuff or how quickly it responds. Some things were slower in urxvt and then some things didn't work as correctly as in xterm, so I didn't bother configuring urxvt for more speed. st, on the other hand, wasn't faster and actually was heavier memory-wise when I tried it the last time.
I ran some benchmarks with perf stat a while back, consisting of displaying a multi-MB text file on screen. st was a lot slower than urxvt, but on par with VTE based terminals. urxvt has other problems though, so I'll stick with st.
To try out a new library, I like example code. But for any serious work, docs are mandatory! I am certain a lot of us have chosen one library over another because "documentation for B is non-existant". So, yes. If you have 0 documentation for a single file library with 10 functions that is stateless, probably. But for anything more complex, show me the docs.
> You are writing the library for evaluators and new users.
Again, feels like a poor suggestion despite the next statement that tries to justify it isn't. In my last job, some choices had been made about a graphing library just because default pie/bar charts were easy to draw with it. As the project grew, all hell broke loose because the library did very little to help customize/extend charts and had close to 0 doc. Even for an open-source project, read the source isn't a very pleasant suggestion especially when I am only interested in using the library and not really learning the art of generating charts.
Isn't the AoCP series a little too dense to be read as an ebook? It isn't really organized as a reference and requires one to pore over it for a long time. Not having a mobi/epub also rules out several good ebook readers. Are there good ebook readers that have e-ink but still manage to render PDFs well? My Kindle Paperwhite is trash at PDFs.
Apple and Microsoft have much to lose if they are found distributing malware. You on the other hand have just written your first GA program and have admitted that the source is ugly. What is the last time you were OK about running an executable from a shady site?
Let's not beat up on the OP too much for not releasing source. It's a very complex program and in an initial state is surely messy code (we've all been there).
Just in case it came out the wrong way, kudos to the OP for getting the job done. I just found his argument that the source-code isn't needed because Microsoft doesn't release its sources way off mark.
I have been using this browser for the last 4-5 hours. It is fairly good. However, some pages like Dr. Dobbs and Vivaldi's own forum makes all shortcuts fail. The only solution seems to be to alt-tab to some other window and then use the shortcut. That said, the browser is really neat to use.
I am currently in a big slump and totally lack motivation. I decided to try this out. Am I mistaken or is the sign-up sheet the only thing up currently?
If so, I would recommend you include a message in your automated reply saying that we would receive an invite soon or something on those lines. Currently, I got
> Thank you for signing up for in.do!
which seems to indicate that I am successfully enrolled in the service. However, the main page prompts me to share this with others. While I would definitely share this with others if I find it useful, why would I share something that is for now just a sign-up sheet?
