Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 29 04:46
    yairchu commented #112
  • Nov 29 04:46

    yairchu on master

    fix dependency hash in nix build (compare)

  • Nov 29 04:46
    yairchu closed #112
  • Nov 28 23:41
    fricklerhandwerk edited #112
  • Nov 28 23:37
    fricklerhandwerk opened #112
  • Nov 24 18:31

    yairchu on master

    Close paren also right-to-left … (compare)

  • Nov 24 18:17

    yairchu on master

    Add failing WYTYWIS test Partially revert "Fix parens fo… Updated hlint rule name (compare)

  • Nov 24 17:44

    yairchu on master

    Fix paren keys for RTL input la… (compare)

  • Nov 24 15:10

    yairchu on master

    More redundant pragmas Extract Test.Lamdu.Exec.runJS (compare)

  • Nov 24 15:00

    yairchu on master

    enable more hlint rules Remove redundant LANGUAGE pragm… Extract Test.Lamdu.Code.readRepl (compare)

  • Nov 24 09:31

    yairchu on master

    use fromRight (hlint police) (compare)

  • Nov 23 17:03

    yairchu on master

    Rename ==> operator which has d… (compare)

  • Nov 23 09:36

    yairchu on master

    hlint police on steroids with … (compare)

  • Nov 14 11:47

    yairchu on example-flip-history-fr

    (compare)

  • Nov 14 11:46

    yairchu on example-flip-history-fr

    Revert: remove type annotation,… Revert "Dot is considered an op… (compare)

  • Nov 14 11:43

    yairchu on example-flip-history-fr

    First: Partially revert "Fix pa… Reverse: remove type annotation… Revert "Dot is considered an op… (compare)

  • Nov 13 08:10

    yairchu on master

    Oops remove left-over debug tra… (compare)

  • Nov 12 14:07

    yairchu on master

    Fix new tag animation See http… (compare)

  • Nov 11 23:20

    yairchu on master

    Minor cleanups (compare)

  • Nov 08 09:12

    yairchu on master

    hypertypes changes (compare)

Yair Chuchem
@yairchu
So I guess we can make a proper solution for this without trading off features of our UI framework - for any key that should also emit a char event; we should process it only when the char event also arrives
Chris Gibbs
@atacratic
sounds plausible from where I'm sitting! :)
FWIW Ubuntu 18.04 switches back to GNOME - maybe that's triggered this?
Eyal Lotem
@Peaker
@atacratic Thanks for all the help debugging this! Looking at the glfw code again -- it seems that the calls to both the key callback and char callback are atomically done - one after another. It's very weird that they somehow get split up into two different rawEvents lists on our side
(by atomic I mean - without returning from GLFW's internal processEvent, which calls both before returning)
Chris Gibbs
@atacratic
sounds tricky. no problem, was glad to help! Also great to get a quick patch earlier that's let me have a play today
Eyal Lotem
@Peaker
@yairchu one idea for the bug triggering here: Perhaps we somehow call swapBuffers or pollEvents from a different thread than the main-loop (the latter is unlikely) so that we get to see the state of the lists in between the 2 callbacks
I see that in GLFW 3 they removed swapBuffers auto-calling pollEvents, so that can't explain it, and the pollEvents/waitEvents definitely seems to be from the same thread
Eyal Lotem
@Peaker

@atacratic ok, I'm pretty sure this is about X input-methods. It seems when using input methods with glfw, user code inherently receives duplicate events about the same key that are hard to de-duplicate later :(

Options:
1) Handle key/char events separately, throw away any key events that have potential char duplicates. This loses out the ability to attach functionality to a key like 'a' regardless of its unicode mapping

2) Fork glfw -- and provide more information to the callbacks from glfw - that helps deduplicate.

I think we should go with (2), to avoid limiting the UI/inputs too much
GLFW currently uses the timestamp on the X key events as a hack to detect that the input-method generated a duplicate event, in order to send just the "chars" inside it (which were filtered out in the original key event). If this timestamp was passed on to the callback, then the identical timestamp can be used by lamdu, too. That'd cause us to generate a key-event without a char, and then a char event without a key. And we'd need to avoid handling both
what a mess!
Yair Chuchem
@yairchu
Note that Lamdu can deal with 1's limitation, but we don't want our UI toolkit to be limited to only our needs
Eyal Lotem
@Peaker
thinking more about glfw side -- it sounds like the right thing to do is to give the user callback the chance to handle the key before the IM does. Because the question of which keys are responsible for which chars/events is truly complicated once IM can compose multiple keys to a single char event, and all this potentially overlaps with the program's key handlers
otherwise - if the IM "stole" the key, the program shouldn't handle it (and get overlapped key handling)
Yair Chuchem
@yairchu
I guess I should read about what this input-manager thing's about, but I won't find time for that until the evening. I guess for languages like Chinese with many characters you do several key strokes per character, and we'd need to not handle those as several shortcut keys but as a character..
Eyal Lotem
@Peaker
Yeah, it's for composing a single input char via multiple keys, and it's not done by the X system in a way that hides it from the app, but the app opts in by giving it to X via XFilterEvent
Yair Chuchem
@yairchu
going down the rabbit hole of input methods, and just suggested an API change for glfw - https://github.com/glfw/glfw/issues/1140#issuecomment-434104005
Yair Chuchem
@yairchu

I'm preparing a slides/talk version of our recent video for presenting at LIVE next week - any comments are welcome -
https://www.dropbox.com/s/tttq763g7yxl214/Scaling%20the%20REPL%20Experience%20Talk%20wip.pdf?dl=0

(it leaves room for demos and talking so I guess it requires some imagination to follow)

Yair Chuchem
@yairchu
@atacratic can you check again now with the master branch?
I've half solved, half worked-around the problem, by not trying to de-duplicate key events and char events but then not handling those redundant key events in our event maps.. Mean-while will try to solve it properly at the UI framework & GLFW level.
Chris Gibbs
@atacratic
@yairchu sure, will try tonight and let you know!
Chris Gibbs
@atacratic
@yairchu It works! :-) nice one :thumbsup:
Yair Chuchem
@yairchu
@atacratic awesome! thanks :) we'd cut a new release sometime soon. we've also discovered other serious bugs (https://trello.com/c/OuaLvwiJ/445-wrong-parenthesis) which we need to first before cutting a release, but right now me and @Peaker are at SPLASH so not much time for that this week..
Chris Gibbs
@atacratic
ok cool, hope you're having a great time!
Yair Chuchem
@yairchu
@atacratic it took a bit of time but the new release is now out! If you could verify on it that the char events indeed work at your setup I'd be grateful :)
Chris Gibbs
@atacratic
@yairchu have tested it - it works! :-)
Edward
@edward309

Hi Yair, Peaker and co,

I've just discovered your work - very compelling! - and after having read your website briefly and opened the IDE, I've got a question for you:
Is there a language specification for Lamdu?

I can see a brief tutorial which I plan to work through, but I'm keen to see the details of how this language differs from Haskell. And whether there's a possibility for interoperability with existing Haskell libraries (which I know sounds like a stretch).

Yair Chuchem
@yairchu
Hi!
One thing to note that the language is not complete yet (for example we don't yet type-classes).
As for main differences from Haskell:
  • Keyword arguments rather than currying is the recommended way to express multiple arguments to a function (which is just a syntax sugar for providing a function with a structural record of arguments)
  • Structural typing (and nominal-types/newtypes also available)
  • Explicit lazy evaluation (evaluation is strict by default)
These are all things which we believe fit well with an editor helping you to type code. More on that in https://medium.com/lamdu-blog/designing-programming-languages-with-ides-in-mind-de890989dfa
Yair Chuchem
@yairchu
At the moment we only compile to JS, but once we make a native compiler we will want to look into interoperability :)
Yair Chuchem
@yairchu
As for specification, currently it's only form is in the code - there's the "Lamdu Calculus" which is a very simple language which is how the code is stored -
https://github.com/lamdu/lamdu-calculus/blob/master/src/Lamdu/Calc/Term.hs
And there's the "Sugared" language, which is how the code is displayed - where for example pattern matching booleans gets sugared to an if-expression. Declared at https://github.com/lamdu/lamdu/blob/master/src/Lamdu/Sugar/Types/Expression.hs
Edward
@edward309
Thanks Yair!
Edward
@edward309
Sounds like it will feel a lot like Haskell to write, but with greatly increased productivity.
(If it one day allows the programmer to utilize Haskell libraries relatively straightforwardly, then I think Lamdu will be an obvious choice for a functional programmer; very little effort/'cost' to adopt. With other languages, I'm fairly sure that I spend more time fixing syntax errors and examining execution of buggy code 'through a pinhole' than I do writing new code. Your explanation in the video was a new angle on this for me.)
Yair Chuchem
@yairchu
That's the goal :) But we still have a way to go in implementing missing features such as type-classes and making a native code compiler
Eyal Lotem
@Peaker
Edward, thanks for the feedback! We do have a bit of documentation at https://github.com/lamdu/lamdu-calculus/blob/master/README.md
Janus Troelsen
@ysangkok

so we're leaning towards the coherence-via-type-indices+reflecting-instance-choice-in-types idea at the moment

did you make a decision regarding the type class coherence? how does that decision interplay with the different methods of compiling type classes away? http://okmij.org/ftp/Computation/typeclass.html

Janus Troelsen
@ysangkok
(quote was from Aug 28 2017)
Yair Chuchem
@yairchu
@ysangkok it wasn't time to make the decision yet, mostly worked on ironing out the editing experience. However we are currently in the process of re-implementing the type-inference and type language towards adding features so will definitely read your reference :)
Janus Troelsen
@ysangkok
How the talk go?
Yair Chuchem
@yairchu
Hi! The talk went great! We were preparing for 45 minutes but then it was only 30, so some content was touched too quickly..
I think that a video of it will be uploaded, for now the slides (which are mostly just a table-of-contents) are available here https://docs.google.com/presentation/d/1nUoyrKRx8GBLOFIc85gK_ZM4P1FyULLpWTJLv3Vddc8/edit#slide=id.p
(btw the slides need to be viewed in presentation mode because there are some animations uncovering columns of a comparison table by removing white rectangles)
Adrian Legaspi
@akilegaspi
Hi everyone, I want to contribute to the development of lambdu, are there any pending tasks that are needed to be tackled?
Eyal Lotem
@Peaker
@akilegaspi Awesome! There are a whole lot of pending tasks in various areas. Would love to discuss with you what appeals to you to work on -- and also dive into the codebase to get you started
Adrian Legaspi
@akilegaspi

@Peaker I want to be working on more of the backend data processing side, particularly how the inputs are handled.

I've already looked at the GitHub issues and it seems like the Datatype creation would be needing some help.

Eyal Lotem
@Peaker
Great! Lamdu is a native app - so the frontend/backend are internal modular divisions. Type editing is currently waiting on a change we're doing to how ASTs are represented, that would allow annotating each subterm in the type-level. These annotations will be used to give identities to subterms so tracking diffs is at a fine-grained level that is easy to later merge (with structural revision control)
For type editing:
1) Our Type AST needs to support annotations -- this item is almost complete.
2) Type sugaring needs to annotate with actions to do the edits, including "type holes" which are like value holes, for editing an incomplete type
3) In the GUI, we need to expand TypeView to TypeEdit, that uses these actions
4) Add "Nominal Type Edit" panes in addition to the REPL pane and definition-edit panes
Janus Troelsen
@ysangkok
reimplemented factorial in current master https://imgur.com/a/Hx8TEpZ :D
congrats on completing the transition to syntax-tree
Eyal Lotem
@Peaker
Thanks! :)