Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 02:17

    gilch on master

    fix inconsistent comment style add namespace output to munging… factor out QUOTEZ format string and 7 more (compare)

  • 02:17
    gilch closed #111
  • 02:16
    gilch opened #111
  • 02:15

    gilch on restyle

    change MAYBE value again So it… (compare)

  • Sep 24 03:34

    gilch on restyle

    fix inconsistent comment style add namespace output to munging… factor out QUOTEZ format string and 5 more (compare)

  • Sep 22 01:13
    bhougland18 starred gilch/hissp
  • Sep 20 04:42

    gilch on plainly-tutorial

    (compare)

  • Sep 20 04:42

    gilch on master

    clarify escape sequences split off Unicode Normalization… clarify string reading with int… and 10 more (compare)

  • Sep 20 04:42
    gilch closed #108
  • Sep 20 04:31
    gilch opened #108
  • Sep 20 04:28

    gilch on plainly-tutorial

    move unicode normalization sect… (compare)

  • Sep 20 04:23

    gilch on plainly-tutorial

    clarify escape sequences split off Unicode Normalization… clarify string reading with int… and 8 more (compare)

  • Sep 19 00:37

    gilch on master

    add more functional library rec… clarify install instructions word as single and paired for c… and 9 more (compare)

  • Sep 19 00:37
    gilch closed #107
  • Sep 19 00:37
    gilch commented #107
  • Sep 19 00:36
    gilch opened #107
  • Sep 19 00:35

    gilch on fun-faqs

    activate readline for LisspREPL revise and add more to FAQ (compare)

  • Sep 18 03:42

    gilch on fun-faqs

    mention more bytes reader macros split ready from stable move sidebar back in real order… (compare)

  • Sep 18 00:21
    HoangTuan110 starred gilch/hissp
  • Sep 16 23:21

    gilch on fun-faqs

    make more quickstart clarificat… (compare)

mjobuda
@mjobuda
and there are still enough c++ developers who are of a different opinion
that C++ is very simple
and nobody has to make mistakes in memory handling
gilch
@gilch
And yet some Mozilla people got so frustrated with it, they had to invent Rust.
gilch
@gilch
Macros are not working right in Lily.
Fully qualified seems to work, but I can't abbreviate them. I tried both prelude and alias.
Probably the compiler and reader don't have access to the global namespace.
mjobuda
@mjobuda
probably, i saw options like this in some invocations, but I 1)am new to hissp 2)this is a proof of concepts and bugs like this are to be expected
but as a proof of concept i convinced myself that this is a good approach
i did also look at the lissp repl source code, but it looked like for me that it is less work/(produced functionality) for me to make the lily repl from ptpython then from lissp repl. Even if i would havee decided for the other way round I still would use the python-prompt-toolkit because it has by far more features then anything comparable. And it's in python so it would good integrate with the lanugages here used
mjobuda
@mjobuda
now i think of embedding it into nvim. Since nvim is in python and ptpython has the feature to be embedded it could be an easy task
mjobuda
@mjobuda
the guy bfrom the hy book claimed that it's the bottom-up design process that is superior and more fun and that lisps are perfect for this
mjobuda
@mjobuda
I try this thesis and create all of my tools myself(and some minimal invasive libs) to do a simple webproject. Macros could be perfect to protect me from boilerplate management
this would be my client side library
and on serverside i would like to have something like:
Route('/users/{user_id:int}', user)
Route('/floating-point/{number:float}', floating_point)
Route('/uploaded/{rest_of_path:path}', uploaded)
this should have generated ALL boilerplate for development and production
mjobuda
@mjobuda
names for {something} should generate variable definitions. I see that frameworks force the developer to write code fior stuff like that from hand. It's no big deal, but the plan is to have everything minimal and Zen. And easy and simple
I should be able to edit the sourccode with the combined repl/editor tool and all server and client(html) related stuff should be automatically generated and refreshed on changes
mjobuda
@mjobuda
a second option for the editor would be webbased. prompt-toolkit can generate html. I don't know how well that works. The editor panel could be in this case something notebook based
class LisspReplLexer(RegexLexer):
tokens = {
'root': [
(r'^#> .\n(?:^#...\n)', using(LisspLexer)),
(r'^>>> .
\n(?:... .\n)', using(PythonConsoleLexer)),
(r'.*\n', pt.Text),
]
}
You suggest to use ONE combined lexer for the whole output(i did that manually in lily)
gilch
@gilch
Gitter chat uses Markdown. You can indent code blocks 4 spaces or use backtick fences. Ctrl+Shift+M to bring up the Markdown help.
The combined lexer is for the REPL sessions shown in the docs. In the modified Lily code I posted, it only imported LisspLexer, not LisspReplLexer.
gilch
@gilch
repl.py, line 82 in the Lily release, you've got Lissp(ns=None). This should be the globals instead. Not sure how you get that from ptpython. It also doesn't have to be set in the constructor. You could do it after, as long as you do it before it needs a macro.
Maybe self.get_globals()?
Yep, that worked.
Not for the reader macros though.
gilch
@gilch
class PythonRepl(PythonInput):
    def __init__(self, *a, **kw) -> None:
        self._startup_paths = kw.pop("startup_paths", None)
        super().__init__(*a, **kw)
        self._load_start_paths()
        self.lissp = Lissp(ns=self.get_globals())
This was enough to get the compiler macros working, but not the reader macros. Not sure what's going on. Are you using some other reader somewhere else?
gilch
@gilch
Found the problem: validator.py line 25 has a Lissp(ns=None).
Multiline strings don't work.
You should probably try the whole quickstart in Lily. That covers most of the syntax.
mjobuda
@mjobuda
I did start again. I had only to import ptpython and override one eval function to get most of the functionality.
ptpython.repl.PythonRepl.run_and_show_expression = newEval
mjobuda
@mjobuda
but I think that ptpython is only for a good start(although I am impressed how much functionality we get for free here)
because what I see here is several text editor widgets 1) one showing output 2) one showing history 3) one command launcher
and they are connected with each other, by using keystrokes one can command these and modify their contents
mjobuda
@mjobuda
One could use a stripped down version of Vim and configure it. Each would use the LisspReplLexer and has it's keybindings. Thus the command launcher would use "ENTER" for sending it's content to the REPLand history (and zeroing it). Whereas KEY-UP and KEY-DOWN would change the content of the editor. The history-viewer could also be just a vim instance in readonly mode with keybindings for sending parts of the buffer to the REPL. And one buffer for editing a sourcefile where there would also be a keystroke to run evrything. I could even imagine that gitter could be used to send code in both sides. Then this would become a tool for "collaborative literate programming".
gilch
@gilch
Lily is still not quite working right. Prompts are different. Highlighting is wrong in places. Multiline inputs usually don't work.
Macros work this time though.
mjobuda
@mjobuda
Thank you for the review. Can you be more detailed? like in which places the highlighting is wrong. How prompts are different? And in which case multiline work and when not. I'm not sure whether macros and autocompletion works right. (I still don't know how the namespace thing works here). Preferably here: https://github.com/mjobuda/lily/issues
gilch
@gilch
@mjobuda I've added some issues. Are you monkeypatching ptpython? Wouldn't that make it hard to develop a ptpython app using Lily?
mjobuda
@mjobuda
I think monkeypatching is the right approach. And I wouldn't use a derogatory term here. It's just proper used OOP inheritence. It should be done like that here. Or to put in another way: Ptpython should have adopted a design that makes it possible to choose which interpreter to use at the prompt. So in such a case this wouldn't be monkeypatching but configuration. Configuration of a general prompttool should be done by setting the interpreter, the highlighter and the autocompleter. No, no, no. Using frameworks is monkeypatching. Writing plugins for VSCode or intellij is much worse then monkeypatching. This here is intelligent opensource design. The whole GNU and linux projects were huge monkey open air festivals. And I'm not developing a prompt. I'm developing an IDE and all tools that I need for development. As the prompt module I chose ptprompt, as the editor and viewer vim. So is this monkeypatching ptprompt or monkeypatching vim? And what If I throw in firefox with a custom plugin? Monkepatching firefox? Do you know what atom and vscode are? They consist of a monkeypatched JS runtime, cut out from the browser and misused as a monkeypatched version from the commandline(nodejs). Then someone monkeypatched again a browser to become a runtime for standalone applications(electron). And then people write plugins for these beasts which have to be configured on a few places and weigh hundred of megabytes.... These are very stupid, fat and greedy animals if you ask me!! Rumble in the jungle!! Monkeys are super cool!
as for the general approach: If I can save time then I will do it. I spent enough hours on reflecting about opensource software. The result is: Everything goes. And if a monkeypatched aproach will deliver a better result I go with the monkeys(my favorite animals btw). Oh, check the history of emacs. Also a prime example from the jungle.
mjobuda
@mjobuda
Or Apache. The queen in the jungle! As the name implies it's completely made up of patches. Do you think that a carefully designed product like Microsoft Windows 98 is better? Really? Look at the sourcecode of lily. It's one short file at the moment. That's not monkeypatching but configuration. I just have to figure out how! Look at your repl: It's a monkepatch of python's basic repl. Great programmers REUSE code, that was the mantra when I learned coding. And now what? Everybody keeps on reinventing the wheel and people seem to get paid for the number of LoC that they produced!! People are using high level programming languages in order to solve problems with more loC then having had this done with Assembler!!! And they call this good design and architecture!!! Monkeys are the smartest and coolest animals out there and the place of old fat crocodiles and hippos are the swamps!!! And not the palace. I did initially try to develop a REPL with babashka with ptprompt-toolkit. Then I discovered Hy&friends. It seems that Hy solved all the problems that clojure had (and babashka partly solved by using rocket science from another galaxy) just by being based on python!! No slow startup times, no complex import mechanisms, you can use it for system programming right away. There are also wrappers in python for getting all unix system tools into the namespace. And nobody uses it!! If one person adds a few lines of code to change the behaviour you'll call it a monkey patch, if 10 persons contribute to it then it's an own prohect which is based on something. BS!!! Python is such a high level language that you definetly should monkeypatch everything you can with it. Otherwise you are not using the full potential of the language. The whole thing is to get the most stuff done with the least amount of time. And once you monkeypatched the thing then I'd like to have wrapped it up in a simple language that is designed for macroprocessing!! An automated monkeypatcher generator!
mjobuda
@mjobuda
lispmonkey.png
gilch
@gilch
@mjobuda "Monkeypatching" is a term of art for a programming technique with certain tradeoffs, not a slight. I don't understand this defensiveness. I've already released Hissp with the very permissive Apache license, so you don't need any further blessing from me to pretty much do what you like with it.