[github]
[slamdata/slamdata] New comment by garyb on pull request #2125: Added are you sure you want to leave this page dialog while unsaved changes
The reason that was introduced is not to aid discoverability, although it's a happy consequence of that restriction. It's to ensure adding members to libraries does not break things that depend on it downstream. The same thing doesn't apply to constructors, since changing the constructors of a type is a breaking change anyway.
I get where you're coming from, I just prefer to do as little as possible when it comes to managing imports, since they're there as a necessary evil, not something that I really want to think much about when solving problems.
hiding (blah)
is still an open import.
(..)
now =D
enableOnBeforeUnloadConfirmation
in saveWorkspace
also, and then trigger disableOnBeforeUnloadConfirmation
at the end of the save, removing it from queueSave
. There are places where saveWorkspace
is called directly, so we'd this behaviour for those as well as the debounced version.
Fix indicator overflow - Gary Burgess
slamdata/slamdata@c3cfd54` Merge pull request #2131 from garyb/indicator-overflow - Gary Burgess
[github]
[slamdata/slamdata] New comment by safareli on issue #1481: Add charts color editing / chart color palette picker (assigned to safareli, cryogenian)
While I was flying with no internet I have fetched some materials and implemented cubehelix schema. in this scheme brightness is perceived as increasing which is what we want for sequential schemes and gives great results. here is an one example https://bl.ocks.org/mbostock/11415064
Will open PR on this issue sharkdp/purescript-colors#30)
Meanwhile this is that I got:
<img width="433" alt="screen shot 2017-08-25 at 8 34 06 pm" src="https://user-images.githubusercontent.com/1932383/29727565-c2a20af8-89d4-11e7-9ef8-c31e58cef6c6.png">
<img width="443" alt="screen shot 2017-08-25 at 8 33 57 pm" src="https://user-images.githubusercontent.com/1932383/29727568-c43d674a-89d4-11e7-9238-8b5d3d12016f.png">
<img width="430" alt="screen shot 2017-08-25 at 8 33 43 pm" src="https://user-images.githubusercontent.com/1932383/29727572-c747aaa4-89d4-11e7-860a-2f81bb9bdd84.png">
<img width="444" alt="screen shot 2017-08-25 at 8 34 42 pm" src="https://user-images.githubusercontent.com/1932383/29727586-d8e12786-89d4-11e7-98ea-c8c9df7e10e9.png">
This is great result as even for 20 stops, brightness difference is still perceived!
[github]
[slamdata/slamdata] Pull request submitted by Cmdv
slamdata/slamdata#2132
Directories with large amount of folders can take time to become visible.
Added a spinner as shown bellow: :point_down:
this fixes #1830
[github]
[slamdata/slamdata] New comment by Cmdv on issue #2128: Filesystem potential memory leak
I agree with what you are saying but the fact that everything returns to being normal speed wise when you refresh the page is what drew me towards my suspicions.
Feels like event listeners should be garbage collected once the folder has been created, yes the repaint/nodes will increase as the number of files do the same. But if there wasn't some potential leak then refreshing the page shouldn't make a difference?
It's also really hard to nail things down as when you search through the code in the profile it's just endless anonymous
functions.
You can have a look at the zip file I attached, inside is a .json
which can be loaded into the performance tab (right click anywhere inside panel)
<img width="555" alt="screen shot 2017-08-25 at 21 05 37" src="https://user-images.githubusercontent.com/3036557/29730715-4499c39e-89d9-11e7-94e6-7346879a12ee.png">
[github]
[slamdata/slamdata] New comment by natefaubion on issue #2128: Filesystem potential memory leak
Feels like event listeners should be garbage collected once the folder has been created
Not sure what you mean. Every row has event listeners on it, so as you add rows, new event listeners are created. Why would adding new rows remove event listeners?
[github]
[slamdata/slamdata] New comment by natefaubion on issue #2128: Filesystem potential memory leak
I think that Chrome is just taking a long time to garbage collect the nodes and handlers. When I initiate a manual garbage collection, things clear up, as indicated by this profile:
<img width="812" alt="screen shot 2017-08-25 at 1 24 31 pm" src="https://user-images.githubusercontent.com/144058/29731324-dce1a5d6-8998-11e7-94ac-762d6a5c47bd.png">
[github]
[slamdata/slamdata] New comment by natefaubion on issue #2128: Filesystem potential memory leak
<img width="802" alt="screen shot 2017-08-25 at 1 36 50 pm" src="https://user-images.githubusercontent.com/144058/29731738-7bbbeff8-899a-11e7-9a89-05f1df8b5a17.png">
In this timeline, I started the recording by hitting garbage collect, adding a bunch of folders, navigating to the root, and then hitting garbage collect again, where the memory returns to what it was originally.
[github]
[slamdata/slamdata] New comment by natefaubion on issue #2128: Filesystem potential memory leak
<img width="153" alt="screen shot 2017-08-25 at 1 42 43 pm" src="https://user-images.githubusercontent.com/144058/29731934-4ed94692-899b-11e7-8ba6-d7d29a043d84.png">
Additionally, here I took a heap snapshot at the root, then after adding a bunch of folders, and then after navigating back to the root again.
[github]
[slamdata/slamdata] Issue created by damonLL
slamdata/slamdata#2133
The icons near the _"Page X of Y"_ control are flipped. The behavior based on their location is correct, but the icon is incorrect.
The first page icon (|<
) and previous page icon (<<
) should be flipped.
Similarly the next page icon (>>
) and last page icon (>|
) should be flipped.
This has been my experience with applications containing pagination controls. The first page and last page icons are typically on the outside of the icon set. I don't think this is a regression, it has been this way for as long as I can remember.
[github]
[slamdata/slamdata] Issue created by damonLL
slamdata/slamdata#2134
When I have a series of data in a line chart, I don't see the legend near the bottom for the colors like I do in the bar chart. See screenshot below.
<img width="615" alt="linechart-legend" src="https://user-images.githubusercontent.com/7375598/29733834-57ecf6a0-89ac-11e7-95d4-23cb03242fe7.png">
>|
and >>
should be swapped (etc.), not that they need flipping to face the opposite direction, right?
[github]
[slamdata/slamdata] New comment by safareli on issue #1481: Add charts color editing / chart color palette picker (assigned to safareli, cryogenian)
I have switched to cubehelix based palettes. here you can see difference:
<img width="1224" alt="screen shot 2017-08-26 at 1 13 48 am" src="https://user-images.githubusercontent.com/1932383/29739575-e5c3be1e-8a51-11e7-9e2c-8d6909944999.png">
One of the main feature is that if you use grayscale for example all cubehelix based palettes have linear change of lightness, which makes it much useful when we want many colors of of palette.
(first 3 chapters of paper describes it much better http://astron-soc.in/bulletin/11June/289392011.pdf)
[github]
[slamdata/slamdata] New comment by garyb on pull request #2132: 1830 - loading spinner to filesystem
Could useH.modify (_ { items = Just $ nub $ cons item previous })
here I think
[github]
[slamdata/slamdata] New comment by garyb on pull request #2132: 1830 - loading spinner to filesystem
This is a revert of my fix #2131
[github]
[slamdata/slamdata] New comment by garyb on pull request #2132: 1830 - loading spinner to filesystem
I think it might have done this slightly differently actually. Instead of defining this DSL-based function I'd probably have just defined it purely (State -> Array Item
). That way it can be used with gets
for the few cases that need it that way, and for the rest it can be applied to the s
in the modify
cases. It's more declarative that way, rather than happening as separate imperative steps.
I'm not saying it needs changing, just giving my 2p on code style/design for this kind of thing.
[github]
[slamdata/slamdata] New comment by garyb on pull request #2132: 1830 - loading spinner to filesystem
Perhaps move this below eval
?
local
being the name of the Mimir mount in the file system, for now at least.