-
Notifications
You must be signed in to change notification settings - Fork 323
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
Small changes from Book Club issues #6533
Conversation
column
.a638ad6
to
6526b2d
Compare
distribution/lib/Standard/Table/0.0.0-dev/src/Internal/Widget_Helpers.enso
Show resolved
Hide resolved
public static TemporalAdjuster day_start = | ||
(Temporal temporal) -> { | ||
return temporal.isSupported(ChronoField.NANO_OF_DAY) | ||
? temporal.with(ChronoField.NANO_OF_DAY, 0) | ||
: temporal; | ||
}; | ||
|
||
public static TemporalAdjuster day_end = | ||
(Temporal temporal) -> { | ||
return temporal.isSupported(ChronoField.NANO_OF_DAY) | ||
? temporal.with(ChronoField.NANO_OF_DAY, NANOSECONDS_IN_DAY - 1) | ||
: temporal; | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This logic seems concerning to me.
I guess it should be fine, but what if we have a date object that supports hour/minute/second but not nanosecond? It will not be adjusted by this.
Shouldn't we just throw if temporal.isSupported
returns False?
I assume you maybe want this to work like identity on Date
- OK. But maybe then we can do some more robust check for if this supports <1day
granularity?
Maybe it's ok, but it just feels to me that there are more possibilities than "support nanos of day" vs "not support day parts at all" and so it seems safer to handle the 'possibility in the middle' at least by throwing an exception that we did not expect it, instead of returning identity. But maybe I'm a bit too picky here.
@@ -229,6 +229,22 @@ spec_with name create_new_date parse_date = | |||
(create_new_date 2000 7 1).end_of Date_Period.Quarter . should_equal (Date.new 2000 9 30) | |||
(create_new_date 2000 6 30).end_of Date_Period.Quarter . should_equal (Date.new 2000 6 30) | |||
|
|||
Test.specify "should allow to compute the number of days until a date" <| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also add tests for the next
method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes I want to add tests for next
, previous
and until
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, as long as the widgets work in the IDE :)
I guess ideally would be good to attach some screenshots if possible.
- Remove custom `Join_Kind` dropdown. - Remove custom `Value_Type` dropdown. - Adjust split and tokenize names to start numbering from 1 not 0.
- Add `days_until` and `until` to `Date`.
Database widgets.
b4cb90e
to
2022874
Compare
- end: the end date of the interval to count workdays in. | ||
- include_end_date: whether to include the end date in the count. | ||
By default the end date is not included in the interval. | ||
days_until : Date -> Boolean -> Integer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps this logic could be part of Period so it could be used in more ways.
…to ` n` (#6587) * change defaults * update tests * update tests * change _ to ' ' * WIP - add location * finish problem builder refactor * adapting other places and tests * docs
* develop: (28 commits) Add tests for Date.until, Date.next and Date.previous. (#6606) Improve `Non_Unique_Primary_Key` error, split file format detection into read/write, improve SQLite format detection (#6604) tokenize_to_columns or parse_to_columns results in a single column we shouldn't add the 1 (#6607) Fix node editing race condition (#6594) Add format to the in-memory Column (#6538) Fix dashboard issues (part 2) (#6511) Fix visualisation type selector artifacts rendered after node preview visualisation was closed. (#6575) Revert typescript CI Lint changes (#6602) Fix the Engine version check in GUI (#6570) Show error pop-up when failing to rename a project (#6366) Small changes from Book Club issues (#6533) "at_least_one" flag for tokenize_to_rows (#6539) Benchmark Engine job runs only engine, not Enso benchmarks (#6534) Catch 5813 and avoid crash (#6585) Fix opening links in desktop IDE (#6507) Identify SyntaxError exception and avoid printing a stack trace (#6574) Fix dashboard issues (#6502) Let ChangesetBuilder.invalidated search even container elements (#6548) Fix #5075: stop panning on full-screen visualisation (#6530) Only `Join_Kind.Inner` removes the common-named columns (#6564) ...
Pull Request Description
column
.Join_Kind
dropdown.days_until
anduntil
toDate
.Date_Period.Day
and createnext
andprevious
onDate
.File_Format
dropdown.Main.enso
based imports inStandard.Base.Data.Map
andStandard.Base.Data.Text.Helpers
.Standard.Database.Data.Table
.From #6587:
A few small changes, lots of lines because this affected lots of tests:
Table.join
now defaults toJoin_Kind.Left_Outer
, to avoid losing rows in the left table unexpectedly. If the user really wants to have an Inner join, they can switch to it.Table.join
now defaults to joining columns by name not by index - it looks in the right table for a column with the same name as the first column in left table.Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
./run ide build
.