Getting started with Datomic and Clojure in Emacs - clojure

My project.clj file looks like this
(defproject cljs-template "0.1.0-SNAPSHOT"
:description "FIXME: write this!"
:url "http://example.com/FIXME"
:dependencies [[org.clojure/clojure "1.4.0-beta4"]
[noir-cljs "0.3.0"]
[fetch "0.1.0-alpha2"]
[noir "1.3.0-beta2"]
[org.clojure/core.cache "0.5.0"]
[com.datomic/datomic "0.1.3142"
:exclusions [org.slf4j/slf4j-nop org.slf4j/slf4j-log4j12]]
[ch.qos.logback/logback-classic "1.0.1"]]
:plugins [[lein-swank "1.4.3"]]
;:cljsbuild {:builds [{}]}
:main ^{:skip-aot true} cljs-template.server)
and my /src/cljs_template/server.clj begins as the following:
(ns cljs-template.server
(:require [noir.server :as server]
[noir.cljs.core :as cljs]
[cljs-template.tree :as tree])
(:use [datomic.api :only [db q] :as d]))
I then start up swank, run (in-ns 'cljs-template.server) within it, move my cursor to the end of the (ns) function call, and attempt to run the (ns) method using Ctrl-x Ctrl-e. When I do so, I get the following error.
No message.
[Thrown class java.lang.ExceptionInInitializerError]
Restarts:
0: [QUIT] Quit to the SLIME top level
1: [CAUSE1] Invoke debugger on cause org.apache.lucene.index.IndexWriterConfig [Thrown class java.lang.ClassNotFoundException]
Backtrace:
0: (Unknown Source) java.lang.Class.forName0
1: Class.java:247 java.lang.Class.forName
2: RT.java:2030 clojure.lang.RT.loadClassForName
3: RT.java:417 clojure.lang.RT.load
4: RT.java:398 clojure.lang.RT.load
5: core.clj:5386 clojure.core/load[fn]
6: core.clj:5385 clojure.core/load
7: RestFn.java:408 clojure.lang.RestFn.invoke
8: core.clj:5200 clojure.core/load-one
9: core.clj:5237 clojure.core/load-lib
10: RestFn.java:142 clojure.lang.RestFn.applyTo
11: core.clj:602 clojure.core/apply
12: core.clj:5271 clojure.core/load-libs
13: RestFn.java:137 clojure.lang.RestFn.applyTo
14: core.clj:602 clojure.core/apply
15: core.clj:5352 clojure.core/require
16: RestFn.java:436 clojure.lang.RestFn.invoke
17: fulltext_index.clj:4 datomic.fulltext-index/loading
18: (Unknown Source) datomic.fulltext_index__init.load
19: (Unknown Source) datomic.fulltext_index__init.<clinit>
20: (Unknown Source) java.lang.Class.forName0
21: Class.java:247 java.lang.Class.forName
22: RT.java:2030 clojure.lang.RT.loadClassForName
23: RT.java:417 clojure.lang.RT.load
24: RT.java:398 clojure.lang.RT.load
25: core.clj:5386 clojure.core/load[fn]
26: core.clj:5385 clojure.core/load
27: RestFn.java:408 clojure.lang.RestFn.invoke
28: core.clj:5200 clojure.core/load-one
29: core.clj:5237 clojure.core/load-lib
30: RestFn.java:142 clojure.lang.RestFn.applyTo
31: core.clj:602 clojure.core/apply
32: core.clj:5271 clojure.core/load-libs
33: RestFn.java:137 clojure.lang.RestFn.applyTo
34: core.clj:602 clojure.core/apply
35: core.clj:5352 clojure.core/require
36: RestFn.java:703 clojure.lang.RestFn.invoke
37: db.clj:4 datomic.db/loading
38: (Unknown Source) datomic.db__init.load
39: (Unknown Source) datomic.db__init.<clinit>
40: (Unknown Source) java.lang.Class.forName0
41: Class.java:247 java.lang.Class.forName
42: RT.java:2030 clojure.lang.RT.loadClassForName
43: RT.java:417 clojure.lang.RT.load
44: RT.java:398 clojure.lang.RT.load
45: core.clj:5386 clojure.core/load[fn]
46: core.clj:5385 clojure.core/load
47: RestFn.java:408 clojure.lang.RestFn.invoke
48: core.clj:5200 clojure.core/load-one
49: core.clj:5237 clojure.core/load-lib
50: RestFn.java:142 clojure.lang.RestFn.applyTo
51: core.clj:602 clojure.core/apply
52: core.clj:5271 clojure.core/load-libs
53: RestFn.java:137 clojure.lang.RestFn.applyTo
54: core.clj:602 clojure.core/apply
55: core.clj:5352 clojure.core/require
56: RestFn.java:703 clojure.lang.RestFn.invoke
57: query.clj:4 datomic.query/loading
58: (Unknown Source) datomic.query__init.load
59: (Unknown Source) datomic.query__init.<clinit>
60: (Unknown Source) java.lang.Class.forName0
61: Class.java:247 java.lang.Class.forName
62: RT.java:2030 clojure.lang.RT.loadClassForName
63: RT.java:417 clojure.lang.RT.load
64: RT.java:398 clojure.lang.RT.load
65: core.clj:5386 clojure.core/load[fn]
66: core.clj:5385 clojure.core/load
67: RestFn.java:408 clojure.lang.RestFn.invoke
68: core.clj:5200 clojure.core/load-one
69: core.clj:5237 clojure.core/load-lib
70: RestFn.java:142 clojure.lang.RestFn.applyTo
71: core.clj:602 clojure.core/apply
72: core.clj:5271 clojure.core/load-libs
73: RestFn.java:137 clojure.lang.RestFn.applyTo
74: core.clj:602 clojure.core/apply
75: core.clj:5352 clojure.core/require
76: RestFn.java:421 clojure.lang.RestFn.invoke
77: api.clj:6 datomic.api/loading
78: (Unknown Source) datomic.api__init.load
79: (Unknown Source) datomic.api__init.<clinit>
80: (Unknown Source) java.lang.Class.forName0
81: Class.java:247 java.lang.Class.forName
82: RT.java:2030 clojure.lang.RT.loadClassForName
83: RT.java:417 clojure.lang.RT.load
84: RT.java:398 clojure.lang.RT.load
85: core.clj:5386 clojure.core/load[fn]
86: core.clj:5385 clojure.core/load
87: RestFn.java:408 clojure.lang.RestFn.invoke
88: core.clj:5200 clojure.core/load-one
89: core.clj:5237 clojure.core/load-lib
90: RestFn.java:142 clojure.lang.RestFn.applyTo
91: core.clj:602 clojure.core/apply
92: core.clj:5271 clojure.core/load-libs
93: RestFn.java:137 clojure.lang.RestFn.applyTo
94: core.clj:604 clojure.core/apply
95: core.clj:5363 clojure.core/use
96: RestFn.java:408 clojure.lang.RestFn.invoke
97: NO_SOURCE_FILE:1 cljs-template.server/eval1941[fn]
98: NO_SOURCE_FILE:1 cljs-template.server/eval1941
99: Compiler.java:6465 clojure.lang.Compiler.eval
100: Compiler.java:6455 clojure.lang.Compiler.eval
101: Compiler.java:6431 clojure.lang.Compiler.eval
102: core.clj:2795 clojure.core/eval
103: core.clj:532 swank.core/eval782[fn]
104: MultiFn.java:163 clojure.lang.MultiFn.invoke
105: basic.clj:54 swank.commands.basic/eval-region
106: basic.clj:44 swank.commands.basic/eval-region
107: basic.clj:73 swank.commands.basic/eval968[fn]
108: Var.java:401 clojure.lang.Var.invoke
109: (Unknown Source) user/eval1937
110: Compiler.java:6465 clojure.lang.Compiler.eval
111: Compiler.java:6431 clojure.lang.Compiler.eval
112: core.clj:2795 clojure.core/eval
113: core.clj:100 swank.core/eval-in-emacs-package
114: core.clj:256 swank.core/eval-for-emacs
115: Var.java:409 clojure.lang.Var.invoke
116: AFn.java:167 clojure.lang.AFn.applyToHelper
117: Var.java:518 clojure.lang.Var.applyTo
118: core.clj:600 clojure.core/apply
119: core.clj:107 swank.core/eval-from-control
120: core.clj:330 swank.core/spawn-worker-thread[fn]
121: AFn.java:159 clojure.lang.AFn.applyToHelper
122: AFn.java:151 clojure.lang.AFn.applyTo
123: core.clj:600 clojure.core/apply
124: core.clj:326 swank.core/spawn-worker-thread[fn]
125: RestFn.java:397 clojure.lang.RestFn.invoke
126: AFn.java:24 clojure.lang.AFn.run
127: Thread.java:662 java.lang.Thread.run
I then press 0 to close the stacktrace, and press Ctrl-x Ctrl-e on the (ns) call again, now my error is:
Could not initialize class datomic.api__init
[Thrown class java.lang.NoClassDefFoundError]
Restarts:
0: [QUIT] Quit to the SLIME top level
Backtrace:
0: (Unknown Source) java.lang.Class.forName0
1: Class.java:247 java.lang.Class.forName
2: RT.java:2030 clojure.lang.RT.loadClassForName
3: RT.java:417 clojure.lang.RT.load
4: RT.java:398 clojure.lang.RT.load
5: core.clj:5386 clojure.core/load[fn]
6: core.clj:5385 clojure.core/load
7: RestFn.java:408 clojure.lang.RestFn.invoke
8: core.clj:5200 clojure.core/load-one
9: core.clj:5237 clojure.core/load-lib
10: RestFn.java:142 clojure.lang.RestFn.applyTo
11: core.clj:602 clojure.core/apply
12: core.clj:5271 clojure.core/load-libs
13: RestFn.java:137 clojure.lang.RestFn.applyTo
14: core.clj:604 clojure.core/apply
15: core.clj:5363 clojure.core/use
16: RestFn.java:408 clojure.lang.RestFn.invoke
17: NO_SOURCE_FILE:1 cljs-template.server/eval6292[fn]
18: NO_SOURCE_FILE:1 cljs-template.server/eval6292
19: Compiler.java:6465 clojure.lang.Compiler.eval
20: Compiler.java:6455 clojure.lang.Compiler.eval
21: Compiler.java:6431 clojure.lang.Compiler.eval
22: core.clj:2795 clojure.core/eval
23: core.clj:532 swank.core/eval782[fn]
24: MultiFn.java:163 clojure.lang.MultiFn.invoke
25: basic.clj:54 swank.commands.basic/eval-region
26: basic.clj:44 swank.commands.basic/eval-region
27: basic.clj:73 swank.commands.basic/eval968[fn]
28: Var.java:401 clojure.lang.Var.invoke
29: (Unknown Source) cljs-template.server/eval6288
30: Compiler.java:6465 clojure.lang.Compiler.eval
31: Compiler.java:6431 clojure.lang.Compiler.eval
32: core.clj:2795 clojure.core/eval
33: core.clj:100 swank.core/eval-in-emacs-package
34: core.clj:256 swank.core/eval-for-emacs
35: Var.java:409 clojure.lang.Var.invoke
36: AFn.java:167 clojure.lang.AFn.applyToHelper
37: Var.java:518 clojure.lang.Var.applyTo
38: core.clj:600 clojure.core/apply
39: core.clj:107 swank.core/eval-from-control
40: core.clj:330 swank.core/spawn-worker-thread[fn]
41: AFn.java:159 clojure.lang.AFn.applyToHelper
42: AFn.java:151 clojure.lang.AFn.applyTo
43: core.clj:600 clojure.core/apply
44: core.clj:326 swank.core/spawn-worker-thread[fn]
45: RestFn.java:397 clojure.lang.RestFn.invoke
46: AFn.java:24 clojure.lang.AFn.run
47: Thread.java:662 java.lang.Thread.run
What am I doing wrong? How do I get datomic working in my emacs using swank/slime.

Turns out I was executing the wrong command.
I was running lein deps and getting the following error.
...
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=com.datomic -DartifactId=datomic -Dversion=0.1.3157 -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=com.datomic -DartifactId=datomic -Dversion=0.1.3157 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.apache.maven:super-pom:pom:2.0
2) com.datomic:datomic:jar:0.1.3157
I saw that the README file in the downloaded datomic code also contained mention of adding datomic to my mvn. Naturally (here comes the stupid part) I assumed that they sort of said the same thing.
lein will tell you that you should execute
mvn install:install-file -DgroupId=com.datomic -DartifactId=datomic -Dversion=0.1.3157 -Dpackaging=jar -Dfile=/path/to/file
the README says you should execute
mvn install:install-file -DgroupId=com.datomic -DartifactId=datomic -Dfile=datomic-${DATOMIC-VERSION}.jar -DpomFile=pom.xml
Did you notice that the README instructions also includes a pom.xml file? Neither did I! Yeah, that is important.
Anyway, be sure to also include the pom.xml file. If you were trying to add datomic 0.1.3157 to your mvn repository, you would execute the following in the datomic directory you downloaded.
mvn install:install-file -DgroupId=com.datomic -DartifactId=datomic -Dfile=datomic-0.1.3157.jar -DpomFile=pom.xml

I posted a working project here
my usual suspect in debugging swank problems are:
is leiningen up to date
the version of lein-swank
version of emacs (Emacs 24, I have found to be much more reliable)
leftover old dependencies in the lib dir
EDIT: the correct way to get the datomic jar is as Stephen Cagle says, copied from his comment below:
mvn install:install-file -DgroupId=com.datomic -DartifactId=datomic -Dfile=datomic-${DATOMIC-VERSION}.jar

Related

dcvviewer crashing at launch

I'm trying to connect with dcvviewer to a remote server whose my_config_file.dcv configuration file is given.
When I run the command :
dcvviewer my_config_file.csv
The viewer opens and then suddenly closes.
Setting RUST_BACKTRACE=full for debugging purposes, I get the following stack.
thread '<unnamed>' panicked at 'assertion failed: !display_layout2.is_null()', src/display_layout.rs:789:9
stack backtrace:
0: 0x7f5c06ffea40 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hb070b7fa7e3175df
1: 0x7f5c0705867e - core::fmt::write::hd5207aebbb9a86e9
2: 0x7f5c06fefdc5 - <unknown>
3: 0x7f5c070016f3 - <unknown>
4: 0x7f5c070013df - std::panicking::default_hook::haa3ca8c310ed5402
5: 0x7f5c07001e2a - std::panicking::rust_panic_with_hook::h7b190ce1a948faac
6: 0x7f5c07001ce1 - <unknown>
7: 0x7f5c06ffeeec - <unknown>
8: 0x7f5c07001a42 - rust_begin_unwind
9: 0x7f5c069c4523 - core::panicking::panic_fmt::h8d17ca1073d9a733
10: 0x7f5c069c43ed - core::panicking::panic::hf0565452d0d0936c
11: 0x7f5c06ae46cb - dcv_display_layout_equal_with_epsilon
12: 0x563f87e005c1 - <unknown>
13: 0x563f87e03d55 - <unknown>
14: 0x7f5c06250eae - g_closure_invoke
15: 0x7f5c06264cbc - <unknown>
16: 0x7f5c0627043e - g_signal_emit_valist
17: 0x7f5c06270956 - g_signal_emit
18: 0x7f5c06255824 - <unknown>
19: 0x7f5c06257f34 - g_object_notify_by_pspec
20: 0x7f5c069ffbed - <unknown>
21: 0x7f5c06b0a9ab - <unknown>
22: 0x7f5c06aa54e6 - <unknown>
23: 0x7f5c06106d69 - <unknown>
24: 0x7f5c0610799b - <unknown>
25: 0x7f5c06aa49e7 - <unknown>
26: 0x7f5c06ad6cdc - <unknown>
27: 0x7f5c06f9741c - <unknown>
28: 0x7f5c06f56f9a - <unknown>
29: 0x7f5c062f69ad - g_main_context_dispatch
30: 0x7f5c062f6c00 - <unknown>
31: 0x7f5c062f6ca3 - g_main_context_iteration
32: 0x7f5c06135c4d - g_application_run
33: 0x563f87dfd7a8 - <unknown>
34: 0x7f5c05321d90 - __libc_start_call_main
at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
35: 0x7f5c05321e40 - __libc_start_main_impl
at ./csu/../csu/libc-start.c:392:3
36: 0x563f87dfd7f5 - _start
37: 0x0 - <unknown>
fatal runtime error: failed to initiate panic, error 5
I'm running Ubuntu 22.04 with latest version of dcvviewer (NICE DCV Viewer - version 2022.2 (r4804)).
What can be wrong ?

deployment failure without error: Rmarkdown with parameters

I am trying to deploy an Rmarkdown document to RPubs. Required data are in subfolder /Data of the directory where the app is located. Previous errors were solved by loading some (but, mysteriously, not all) libraries on separate lines ('library(). Now, it says deployment is successful, but the website https://yettas.shinyapps.io/ShinyVEST-lite/ returns:
'Error: Error: An error has occurred. Check your logs or contact the app author for clarification.' Unlike previous attempts, I do not see an Error explicitly listed in the logs (see below). I am not sure what to look for other than the word 'Error'.
Thank you in advance for your help!
2022-11-07T15:57:05.864726+00:00 shinyapps[7537976]: 176:
signalCondition 2022-11-07T15:57:05.864730+00:00 shinyapps[7537976]:
175: signal_abort 2022-11-07T15:57:05.864734+00:00 shinyapps[7537976]:
174: abort 2022-11-07T15:57:05.864742+00:00 shinyapps[7537976]: 173:
h 2022-11-07T15:57:05.864759+00:00 shinyapps[7537976]: 172:
.handleSimpleError 2022-11-07T15:57:05.864763+00:00
shinyapps[7537976]: 171: between 2022-11-07T15:57:05.864771+00:00
shinyapps[7537976]: 170: mask$eval_all_filter
2022-11-07T15:57:05.864774+00:00 shinyapps[7537976]: 168:
filter_eval 2022-11-07T15:57:05.864777+00:00 shinyapps[7537976]:
167: filter_rows 2022-11-07T15:57:05.864780+00:00 shinyapps[7537976]:
166: filter.data.frame 2022-11-07T15:57:05.864787+00:00
shinyapps[7537976]: 165: NextMethod 2022-11-07T15:57:05.864797+00:00
shinyapps[7537976]: 164: stopifnot 2022-11-07T15:57:05.864828+00:00
shinyapps[7537976]: 163: .re_sf 2022-11-07T15:57:05.864838+00:00
shinyapps[7537976]: 162: filter.sf 2022-11-07T15:57:05.864842+00:00
shinyapps[7537976]: 161: filter 2022-11-07T15:57:05.864871+00:00
shinyapps[7537976]: 160: select 2022-11-07T15:57:05.864876+00:00
shinyapps[7537976]: 159: mutate 2022-11-07T15:57:05.864888+00:00
shinyapps[7537976]: 158: %!>(MISSING)%!(NOVERB)
2022-11-07T15:57:05.864906+00:00 shinyapps[7537976]: 157:
new.get.data 2022-11-07T15:57:05.864915+00:00 shinyapps[7537976]:
156: %!>(MISSING)%!(NOVERB) 2022-11-07T15:57:05.864927+00:00
shinyapps[7537976]: 155: eval 2022-11-07T15:57:05.864943+00:00
shinyapps[7537976]: 154: eval 2022-11-07T15:57:05.864966+00:00
shinyapps[7537976]: 153: eval_with_user_handlers
2022-11-07T15:57:05.864971+00:00 shinyapps[7537976]: 148:
evaluate_call 2022-11-07T15:57:05.864975+00:00 shinyapps[7537976]:
147: evaluate::evaluate 2022-11-07T15:57:05.864997+00:00
shinyapps[7537976]: 146: evaluate 2022-11-07T15:57:05.865006+00:00
shinyapps[7537976]: 143: eng_r 2022-11-07T15:57:05.865018+00:00
shinyapps[7537976]: 142: block_exec 2022-11-07T15:57:05.865037+00:00
shinyapps[7537976]: 141: call_block 2022-11-07T15:57:05.865059+00:00
shinyapps[7537976]: 140: process_group.block
2022-11-07T15:57:05.865071+00:00 shinyapps[7537976]: 137:
process_file 2022-11-07T15:57:05.865091+00:00 shinyapps[7537976]:
136: knitr::knit 2022-11-07T15:57:05.865096+00:00 shinyapps[7537976]:
135: 2022-11-07T15:57:05.865109+00:00 shinyapps[7537976]:
130: 2022-11-07T15:57:05.865113+00:00 shinyapps[7537976]:
114: doc 2022-11-07T15:57:05.865142+00:00 shinyapps[7537976]: 113:
renderUI 2022-11-07T15:57:05.865149+00:00 shinyapps[7537976]: 112:
func 2022-11-07T15:57:05.865165+00:00 shinyapps[7537976]: 99:
renderFunc 2022-11-07T15:57:05.865171+00:00 shinyapps[7537976]: 98:
output$reactivedoc 2022-11-07T15:57:05.865190+00:00
shinyapps[7537976]: 17:
2022-11-07T15:57:05.865194+00:00 shinyapps[7537976]: 15:
2022-11-07T15:57:05.865219+00:00 shinyapps[7537976]:
13: fn 2022-11-07T15:57:05.865227+00:00 shinyapps[7537976]: 8:
retry 2022-11-07T15:57:05.865245+00:00 shinyapps[7537976]: 7:
connect$retryingStartServer 2022-11-07T15:57:05.865250+00:00
shinyapps[7537976]: 6: eval 2022-11-07T15:57:05.865269+00:00
shinyapps[7537976]: 5: eval 2022-11-07T15:57:05.865273+00:00
shinyapps[7537976]: 4: eval 2022-11-07T15:57:05.865297+00:00
shinyapps[7537976]: 3: eval 2022-11-07T15:57:05.865323+00:00
shinyapps[7537976]: 2: eval.parent
2022-11-07T15:57:05.865339+00:00 shinyapps[7537976]: 1: local

mips-g++-5.4 listing bnez skips div instruction

I'm trying to understand why mips-g++ compiles a simple division subroutine where it skips the actual div instruction with a bnez v0, <jmp> (pseudo inst for bne). My understanding is that if the divisor is zero it makes sense to skip div and trap or break in this case. Why should it branch if the divisor is not zero?
I would like to learn what I am missing.
subroutine
void do_div(int &a, int &b, int &result){
result = a/b;
}
assembly listing :
(compiler flags: -O0)
00000000 <_Z6do_divRiS_S_>:
0: 27bdfff8 addiu sp,sp,-8
4: afbe0004 sw s8,4(sp)
8: 03a0f025 move s8,sp
c: afc40008 sw a0,8(s8)
10: afc5000c sw a1,12(s8)
14: afc60010 sw a2,16(s8)
18: 8fc20008 lw v0,8(s8)
1c: 00000000 nop
20: 8c430000 lw v1,0(v0)
24: 8fc2000c lw v0,12(s8)
28: 00000000 nop
2c: 8c420000 lw v0,0(v0)
30: 00000000 nop
34: 14400002 bnez v0,40 <_Z6do_divRiS_S_+0x40>
38: 0062001a div zero,v1,v0
3c: 0007000d break 0x7
40: 00001010 mfhi v0
44: 00001812 mflo v1
48: 8fc20010 lw v0,16(s8)
4c: 00000000 nop
50: ac430000 sw v1,0(v0)
54: 00000000 nop
58: 03c0e825 move sp,s8
5c: 8fbe0004 lw s8,4(sp)
60: 27bd0008 addiu sp,sp,8
64: 03e00008 jr ra
68: 00000000 nop
As #EOF mentioned in a comment, MIPS has the concept of branch delay slots.
This is from the description of BNE (emphasis mine):
If the contents of GPR rs and GPR rt are not equal, branch to the effective target address after the instruction in the delay slot is executed.
So the DIV always gets executed. You might think "Well, isn't that a problem if $v0 is 0?". But the description for DIV says that:
No arithmetic exception occurs under any circumstances.
If the divisor in GPR rt is zero, the arithmetic result value is UNPREDICTABLE.
So in the case of a zero divisor you end up with an unpredictable result, which we're not going to use anyway because the next thing that's done is to trigger a breakpoint exception with the BREAK instruction.
Source: MIPS32™ Architecture For Programmers Volume II: The MIPS32™ Instruction Set

Delooping an R code for calculation of overlapping intervals

I have data of this format (snippet):
SW_Release deviceType configStartDate configEndDate
1: 04.05.00 21 2005-11-03 19:12:36 2006-02-28 10:19:27
2: 04.05.00 16 2005-11-04 03:59:05 2006-02-28 10:19:27
3: 04.05.00 20 2005-11-04 03:59:06 2006-02-28 10:19:27
4: 04.05.00 15 2005-11-04 03:59:06 2006-02-28 10:19:27
5: 04.05.00 19 2005-11-04 03:59:06 2006-02-28 10:19:27
6: 04.05.00 17 2005-11-04 03:59:06 2006-02-28 10:19:27
7: 04.07.03 16 2006-02-28 10:19:27 2006-03-29 01:00:39
8: 04.07.03 20 2006-02-28 10:19:27 2006-03-29 01:00:41
9: 04.07.01 15 2006-02-28 10:19:27 2006-03-29 01:00:41
10: 04.07.01 19 2006-02-28 10:19:27 2006-03-29 01:00:41
11: 04.07.01 17 2006-02-28 10:19:27 2006-03-29 01:00:42
12: 04.07.01 21 2006-02-28 10:19:27 2006-03-29 01:00:42
13: 04.07.01 18 2006-02-28 10:19:27 2006-03-29 01:00:42
14: 04.07.04 16 2006-03-29 01:00:40 2006-05-01 16:07:49
15: 04.07.04 20 2006-03-29 01:00:41 2006-05-01 16:07:50
16: 04.07.02 15 2006-03-29 01:00:41 2006-05-01 16:07:50
17: 04.07.02 19 2006-03-29 01:00:41 2006-05-01 16:07:51
18: 04.07.02 17 2006-03-29 01:00:42 2006-05-01 16:07:51
19: 04.07.02 21 2006-03-29 01:00:42 2006-05-01 16:07:51
20: 04.07.02 18 2006-03-29 01:00:42 2006-06-01 09:45:36
21: 04.07.04 16 2006-05-02 09:47:57 2006-06-01 09:45:25
22: 04.07.04 20 2006-05-02 09:47:57 2006-06-01 09:45:28
23: 04.07.02 15 2006-05-02 09:47:58 2006-06-01 09:45:31
24: 04.07.02 19 2006-05-02 09:47:58 2006-06-01 09:45:32
25: 04.07.02 17 2006-05-02 09:47:58 2006-06-01 09:45:34
26: 04.07.02 21 2006-05-02 09:47:58 2006-06-01 09:45:35
27: 04.07.05 16 2006-06-01 09:45:27 2006-08-14 17:54:15
28: 04.07.05 20 2006-06-01 09:45:29 2006-08-14 17:54:15
29: 04.07.06 15 2006-06-01 09:45:31 2007-12-12 11:03:00
30: 04.07.06 19 2006-06-01 09:45:33 2007-12-12 11:03:00
31: 04.07.03 17 2006-06-01 09:45:35 2006-08-14 17:54:16
32: 04.07.03 21 2006-06-01 09:45:35 2006-08-14 17:54:16
33: 04.07.04 18 2006-06-01 09:45:37 2007-12-12 11:03:00
34: 04.07.06 16 2006-08-14 17:54:15 2007-12-12 11:02:59
35: 04.07.06 20 2006-08-14 17:54:15 2007-12-12 11:02:59
36: 04.07.04 17 2006-08-14 17:54:16 2007-12-12 11:03:00
37: 04.07.04 21 2006-08-14 17:54:16 2007-12-12 11:03:00
38: 04.05.12 14 2011-06-17 15:40:13 2012-05-24 11:43:24
I need to add up all the intervals (between second-to-last and last columns), but, as you can see, some rows have overlapping or partially overlapping intervals.
Before I add up all the days, I need to convert the full dataset (from which the above snippet came) into something like:
accumulated data:
configStartDate configEndDate
1: 2005-11-03 19:12:36 2007-12-12 11:03:00
2: 2011-06-17 15:40:13 2012-05-24 11:43:24
total days: 934.296
Here’s my R code for doing this (it has to be R, although I am considering re-writing it in C++ and using RCPP):
merge_intervals <- function(interval_dt){
interval_dt <- interval_dt[order(configStartDate), list(configStartDate, configEndDate)]
new_dt <- interval_dt[1, list(configStartDate, configEndDate)]
for (i in 2:dim(interval_dt)[1]) {
buff <- interval_dt[i, list(configStartDate, configEndDate)]
if (new_dt[dim(new_dt)[1], configEndDate] >= buff[, configStartDate]){
if(new_dt[dim(new_dt)[1], configEndDate] >= buff[, configEndDate]){
next
}
else{
new_dt[dim(new_dt)[1], configEndDate := buff[, configEndDate]]
}
}
else {
new_dt <- rbind(new_dt, buff)
}
}
return(new_dt)
}
Right now the whole thing takes about 0.16 seconds to run (with other calculations), but, for 3000 unique assets, that creates 8 minutes calculation time overhead.
How do I transform that for loop into something faster to reduce calculation time? Thanks!
Something like this?
df <- data.frame(
id = 1:3,
start = Sys.time() + c(0, 1000, 3000),
end = Sys.time() + c(1500, 2000, 4000)
)
library(dplyr)
df %>%
mutate(
overlap = lead(start, 1, default = TRUE) < end,
interval = cumsum(overlap)
) %>%
group_by(interval) %>%
summarise(start = min(start), end = max(end)) %>%
mutate(delta = end - start) %>%
summarise(total = sum(delta))

Why is 0x7FFFFFFFull | (1 << 31) returning 0xFFFFFFFFFFFFFFFF in C++?

When I do (0x7fffffff | 0x8000000) I am getting 0xffffffffffffffff instead of the expected 0xffffffff. What am I missing?
Some sample code and output to illustrate my question.
Code:
#include <iostream>
using namespace std;
int main()
{
unsigned long long val = 0;
for (int i = 0; i < 64; i++) {
val |= 0x1 << i;
cout << i << ": " << std::hex << val << std::dec << endl;
}
return 0;
}
Output:
0: 1
1: 3
2: 7
3: f
4: 1f
5: 3f
6: 7f
7: ff
8: 1ff
9: 3ff
10: 7ff
11: fff
12: 1fff
13: 3fff
14: 7fff
15: ffff
16: 1ffff
17: 3ffff
18: 7ffff
19: fffff
20: 1fffff
21: 3fffff
22: 7fffff
23: ffffff
24: 1ffffff
25: 3ffffff
26: 7ffffff
27: fffffff
28: 1fffffff
29: 3fffffff
30: 7fffffff
31: ffffffffffffffff
32: ffffffffffffffff
33: ffffffffffffffff
34: ffffffffffffffff
35: ffffffffffffffff
36: ffffffffffffffff
37: ffffffffffffffff
38: ffffffffffffffff
39: ffffffffffffffff
40: ffffffffffffffff
41: ffffffffffffffff
42: ffffffffffffffff
43: ffffffffffffffff
44: ffffffffffffffff
45: ffffffffffffffff
46: ffffffffffffffff
47: ffffffffffffffff
48: ffffffffffffffff
49: ffffffffffffffff
50: ffffffffffffffff
51: ffffffffffffffff
52: ffffffffffffffff
53: ffffffffffffffff
54: ffffffffffffffff
55: ffffffffffffffff
56: ffffffffffffffff
57: ffffffffffffffff
58: ffffffffffffffff
59: ffffffffffffffff
60: ffffffffffffffff
61: ffffffffffffffff
62: ffffffffffffffff
63: ffffffffffffffff
Firstly your code does not do what you say in your title/question; I have edited the title.
The problem is 1 << 31. If you have 32-bit int (which apparently you do, judging by the results), this cause arithmetic overflow. In C++14 this is implementation-defined behaviour; prior to C++14 it causes undefined behaviour. Reference.
Usually the implementation-defined behaviour will be to generate the int with the sign bit set and the other bits unset. In 2's complement this value is INT_MIN. You then perform arithmetic between an unsigned long long and an int. This is defined as: the int is converted to unsigned long long.
Converting signed integers to unsigned is done by wrapping it around (modular arithmetic) modulo ULLONG_MAX+1. So the result of (unsigned long long)INT_MIN is a very large positive number, in fact 0xFFFFFFFF80000000. (To check this, add 0x80000000 to it to get 0).
So you are actually doing 0x7FFFFFFF | 0xFFFFFFFF80000000 which gives the observed result.
Later on it gets worse: 1 << 32 and larger causes undefined behaviour due to shifting by the whole width of the type.
To fix this, change 0x1 in your code to 1ull. The you will be shifting an unsigned long long, instead of an int.
because of sign extension val is an unsigned long long. But val is not what you are shifting. You are shifting 0x1, an int, then extending it to long long for the '|='