New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
harmless but annoying bug in amber console #352
Comments
@sam0x17 Hello, sorry that you find it annoying. I would like for you to know that we also find it rather annoying. The ICR shard is the root cause of this behavior. ICR shard basically writes the input statement to file on disk, and for each new statement it will append to the same file causing it to re run all previous statements. We are putting some thoughts on how we can address this issue, and would like your input on ideas you might have around this. Thank you for submitting the issue. |
Hi, First Idea:
|
@eliasjpr yikes! that makes sense. My guess is there is something that could be done in a way that is similar to how in certain scenarios C++ can dynamically load compiled libraries at runtime --- basically we need some way of compiling something and then "injecting" it into an already running scope/context....... 🤔 Like JIT basically |
another hackier possibility that might be a lot easier to implement: prefix lines you don't want ICR to re-run with some sort of marker, so like:
Where I know with the way I work in the Ruby console I'd be able to pretty easily adapt my workflow to this, but it still is a bit confusing probably |
Now that I know this is what is going on, however, I will probably just do very long one-liners with lots of semicolons. Might be good to have some sort of warning printed when ICR loads explaining that every time you enter something all previous lines are re-executed |
Just check context for every modifying action. |
I'm not sure why there is a need to expose a fake REPL that horribly breaks in almost all scenarios that would be used in a web framework's interactive console (e.g. networking, databases). Please just remove |
@oprypin point taken. I think the main motivation is the desire to have a way of quickly executing crystal code in a particular environment (e.g. play with things in your database, etc) without having to create an initializer or using something similar to a rake task just to run a simple one liner. You make a very good point that anything stateful is not going to work and will be completely broken because ICR is basically a hack once you have multi-line code. I totally accept that. Unfortunately people coming from ruby/rails are really going to want some way of running one-liners. Given that, a totally workable solution I think would be something like |
Hi, Why not use We can add an playground folder with an
Then, you go to http://localhost:8080/workbook/playground/myproject And It's a crystal built-in feature. |
@faustinoaq glad to hear that including the environment is that simple. The reason I don't like Now that I know how environment loading works based on what you said, I'd be happy to develop this feature |
@faustinoaq I generally really like |
@sam0x17 Yeah, It would be an alias to
@oprypin Yeah, the issue remains, but at least is clear we shouldn't use ICR nor |
I propose that we replace amber console with amber exec... which we maybe call amber console since |
@elorest I think calling it console might be a bit confusing since it isn't a REPL. I would call it |
We could add |
@faustinoaq yes I think I suggested exactly that a while ago... maybe in chat? 🤔 I think it would be very useful. One of the biggest surprises I've had working with amber is that including the entire environment is really just as simple as a single require statement |
* cli: add "amber exec" command for executing one-liners (#352) * this now behaves as close to a console as we can make it * finishing touches for amber exec * do not run editor unless in editor mode * always return a result * minor wording change in error message * amber exec specs * cleaned up code a bit and copied existing file to new temp file for edits * specs pass yay. MainCommand.run always returns nil which makes testing hard * new push to see if travis passes. Pass locally so I'm confused. * debugging to figure out why travis doesn't pass * added sleeps to see if that works * one last thing * what the what? * i hope this will clear it up * weird hack that i think fixes specs on linux * commented weird hack * native ls had better work * formatted and fixed tests probably * removed some vestigual code. * removed macro flag for now * test47 of travis * namespaces specs * sorted ls results
Resolved with |
* cli: add "amber exec" command for executing one-liners (#352) * this now behaves as close to a console as we can make it * finishing touches for amber exec * do not run editor unless in editor mode * always return a result * minor wording change in error message * amber exec specs * cleaned up code a bit and copied existing file to new temp file for edits * specs pass yay. MainCommand.run always returns nil which makes testing hard * new push to see if travis passes. Pass locally so I'm confused. * debugging to figure out why travis doesn't pass * added sleeps to see if that works * one last thing * what the what? * i hope this will clear it up * weird hack that i think fixes specs on linux * commented weird hack * native ls had better work * formatted and fixed tests probably * removed some vestigual code. * removed macro flag for now * test47 of travis * namespaces specs * sorted ls results
* cli: add "amber exec" command for executing one-liners (#352) * this now behaves as close to a console as we can make it * finishing touches for amber exec * do not run editor unless in editor mode * always return a result * minor wording change in error message * amber exec specs * cleaned up code a bit and copied existing file to new temp file for edits * specs pass yay. MainCommand.run always returns nil which makes testing hard * new push to see if travis passes. Pass locally so I'm confused. * debugging to figure out why travis doesn't pass * added sleeps to see if that works * one last thing * what the what? * i hope this will clear it up * weird hack that i think fixes specs on linux * commented weird hack * native ls had better work * formatted and fixed tests probably * removed some vestigual code. * removed macro flag for now * test47 of travis * namespaces specs * sorted ls results Former-commit-id: 3a55d2a
User
, and give it an attribute called 'email' with a unique constraint on itamber console
u = User.new(name: 'Sam', email: 'test@test.com')
u.save
u
-- you will notice theu
that gets printed has a unique constraint violation error on it, even though the save was actually successful. If you then runu = User.first
, you will see the correctly saved user, without any constraint violation.The text was updated successfully, but these errors were encountered: