im running the December beta emonpi image and last night (around 9am uk time) all my RF received channels stopped updating but my MQTT ones kept working suggesting that most of the system was still alive. The RF module was still blinking its red led suggesting that the radio but was still alive too and a reboot fixed everything.
i recently updated the RFM to the latest version.
Is this a known problem? It's the first time I've seen it.
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
I'm currently experiencing the same issue - see this thread.
Paul
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
The fact that the RFM2Pi's LED continued to blink would suggest the issue is more likely to be on the Pi rather than the RFM2Pi. The best place to look should this reoccur is in emonhub.log. I suspect the RFM2Pi thread may have died but we cannot confirm that as after a reboot, the read-only OS of the emonPi image clears all the logs and any useful info with it.
@Paul - are you still having trouble? I hoped no news was good news as there were no further reports.
Paul
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
I've just updated my thread Paul, but yes, this does seem different as my LED stops flashing.
Paul
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
@PB66, I'm guessing I need to change the logging as currenly /log/emonhub/emonhub.log just contains
2016-01-29 21:44:18,981 INFO MainThread EmonHub emonHub 'emon-pi' variant v1.1
2016-01-29 21:44:18,983 INFO MainThread Opening hub...
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
I also get this issue. 9.3 installation following the raspi installation guide on a PiB on Jessie Lite with USB HDD.
In my case, the rfm12 led is flashing at the 5 second interval but if I look at the emoncms Input View I see that the inputs haven't been updated for a long time. Last time I hadn't checked things for a while and all the inputs were 31 hours since last update (note to self - must set up a notification when this occurs!)
emonhub log shows some errors over the previous hours mainly to do with emoncms send failures, e.g.
2016-01-30 02:49:44,762 WARNING emonCMS send failure: wanted 'ok' but got ''
2016-01-30 03:01:34,797 WARNING emonCMS couldn't send to server, Exception: Traceback (most recent call last):
File "/home/pi/emonhub/src/emonhub_reporter.py", line 227, in _send_post
response = urllib2.urlopen(request, timeout=60) etc. etc. etc.
emonhub status gives:
pi@Homepi-emoncms:~ $ sudo service emonhub status
● emonhub.service - LSB: Start/stop emonHub
Loaded: loaded (/etc/init.d/emonhub)
Active: active (running) since Fri 2016-01-29 16:59:01 GMT; 1 day 18h ago
Process: 331 ExecStart=/etc/init.d/emonhub start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/emonhub.service
└─378 python /usr/share/emonhub/emonhub.py --logfile /var/log/emonhub/emonhub.log --...
Jan 29 16:58:58 Homepi-emoncms emonhub[331]: Starting OpenEnergyMonitor emonHub: emonhub has...ok.
Jan 29 16:59:01 Homepi-emoncms systemd[1]: Started LSB: Start/stop emonHub.
Jan 31 03:12:06 Homepi-emoncms emonhub[331]: Traceback (most recent call last):
Jan 31 03:12:06 Homepi-emoncms emonhub[331]: File "/usr/share/emonhub/emonhub.py", line 338,...le>
Jan 31 03:12:06 Homepi-emoncms emonhub[331]: hub.run()
Jan 31 03:12:06 Homepi-emoncms emonhub[331]: File "/usr/share/emonhub/emonhub.py", line 90, in run
Jan 31 03:12:06 Homepi-emoncms emonhub[331]: values = I.read()
Jan 31 03:12:06 Homepi-emoncms emonhub[331]: File "/home/pi/emonhub/src/emonhub_interfacer.p...ead
Jan 31 03:12:06 Homepi-emoncms emonhub[331]: self._sock_rx_buf = self._sock_rx_buf + conn.re...24)
Jan 31 03:12:06 Homepi-emoncms emonhub[331]: socket.error: [Errno 104] Connection reset by peer
Hint: Some lines were ellipsized, use -l to show in full.
Is there anything else I can check to see what emonhub is doing?
sudo service emonhub stop, then start brings things back to life, inputs start updating every 5 seconds or so.
Simon
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
@Sheppy - yes, I would set a loglevel=DEBUG just to be sure I captured as much info as possible, the loglevel=WARNING may tell you "it's broke" but not give you any insight as to why it broke, in these instances the more info the better usually.
@ Simon - I don't think this is the same issue either because the "break" in your route is between emonhub and emoncms, this is unlikely to be able to differentiate between mqtt and rfm, this thread is about rfm stopping whilst mqtt continues so the issue is most likely between emonhub and the rfm2pi.
However the same applies about the loglevel and the lead up to the fault in your log. the 2 emonhub messages you posted tell us emonhub didn't get the expected response from emoncms and what that response was. It does not tell us if what it sent was likely to get a good response.
Plus sheppy is using the emon-pi variant on the 22dec image not genuine emonhub v1.2 on Jessie-lite. I am pretty confident that your issue will be with (reaching) emoncms not emonhub. possibly another dns/dhcp issue with "lite".
If you are also still having "rfm only" issues as well then we need to revisit your existing RFM2Pi thread.
Paul
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
Hi paul, you're right I shouldn't have hijacked this thread. My issues with rfm have gone away and now I only have this type of failure.
Although I think I need some more info from you, When you say 'your route is between emonhub and emoncms, this is unlikely to be able to differentiate between mqtt and rfm' and 'the 2 emonhub messages you posted tell us emonhub didn't get the expected response from emoncms and what that response was. It does not tell us if what it sent was likely to get a good response.' Can you be a bit more specific. I'd be glad to start up a new thread on these types of issues.
Simon
PS you keep accusing me of having dhcp and dns issues, which i'm sure I haven't got at all accusing is perhaps the wrong word but it'll have to do :-). There was a dns issue on wget which I tracked down to my ISP virgin media with the help of the pi forums but that wouldn't affect this.
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
@pb66 It hasn't failed so far so nothing to report. I'll try and establish a failure pattern and then turn the logging on when a failure is due. Its been up for almost 48 hours so far. Are there any services I can restart when it does fail to narrow it down a bit?
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
@ sheppy - I'd be inclined to just change the loglevel now, you do not need to restart and you can always change it back further down the line if no longer required. The main benefit of the log is to gather data unattended and continuously so that when the issue occurs unexpectedly, data has already been captured that may help establish the cause or pattern.
At the moment we have zero info so I couldn't say what would be a valid test, the logs from when/if it fails will hopefully give us some direction, even if they contain no error codes the continued logging of certain messages may confirm or eliminate certain possibilities.
@Simon - I only suggest a possible dns/dhcp issue when it fits the symptoms, like your example when "There was a dns issue on wget" or when your emonhub warnings and exceptions clearly stated "URLError: [Errno -2] Name or service not known".
If there is a problem with your set up that is preventing emonhub communicating with an emoncms instance on the same machine via http, then the first thing that sprung to my mind was a dns/dchp type issue, a thought I shared with you in hope it may help not offend, my use of the term "another" only casually refers to it not being the first time you will have encountered an issue of this type IF indeed it is of this type, not that is necessarily related.
A new thread maybe a good idea and was the reason for pointing out the difference in issues the first of those 2 comments. Since the messages state emonhub did not get a valid response from emoncms, it is highly unlikely to be specific any one type of input and not others (ie rfm not mqtt as the op reports) and I also commented that emoncms's non-response might actually be due to a bad request from emonhub. I'm not suggesting that is (or isn't) the case, it probably (but not definitely) isn't, but I was only pointing out the information to make a quick and very useful observation isn't present in the short piece of log provided, which was inline with what I was saying to Sheppy about the loglevel at that point.
Paul
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
@pb66 Debug Logging turned on - presumably it will trim it before the tmpfs /var/log runs out of space?
Also is it worth turning on quiet mode? (how?) There's a lot of discarded packets in there
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
emonhub self manages it's logfiles, rotating them at 5mb although if using the emonpi image I believe there may be log rotation at 1mb. Either way, no, emonhub cannot consume the whole /var/log tmpfs partition..
Tough call to make on quiet mode. Yes, less packets may be less difficult to sift through, but if your loss of data is due to packets no longer being seen as valid, or a potential serial issue, the "noise" may be useful. Flip a coin, or go with your instinct if there really are that many. It can be enabled/disabled by setting "quiet = true" or "quiet = false" in the runtimesettings of the RFM2Pi in emonhub.conf. By default, quiet mode is active (true) if there is no entry.
Paul
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
I'll leave it as is, especially as details on this issue are lacking.
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
@Paul, thanks for the (as usual) clear explanation.
Having said that I'm not sure that my issue is different to Sheppy's.
The system stopped passing through data again soon after the last time. I had changed the emonhub log setting to DEBUG in the meantime. You'll see the log below.
Essentially everything was running fine, no warnings about not being able to reach emoncms etc. when suddenly the log stops. You'll see the restart a few hours later. I've highlighted in BOLD the point where I did the service emonhub stop and start to get things functioning again. I haven't done a reboot on the system for a few weeks, just stopped and started emonhub if there has been an issue.
If this occurs again in the future is there any arcane bit of Linux I can use to get an idea of what has happened. You mention the rfm2pi thread in one of your earlier replies. Can I see if that is still running? Or are there any other logs I can look at?
Simon
2016-02-01 03:41:44,253 DEBUG 7585 NEW FRAME :<PHONE_NUMBER>.25 10 46 1 0 0 0 0 0 0 189 94 178 1 122 2 199 1 153 2 114 1
2016-02-01 03:41:44,270 DEBUG 7585 Timestamp :<PHONE_NUMBER>.25
2016-02-01 03:41:44,273 DEBUG 7585 Node : 10
2016-02-01 03:41:44,275 DEBUG 7585 Values : [302, 0, 0, 0, 24253, 434, 634, 455, 665, 370]
2016-02-01 03:41:44,373 DEBUG 7585 Append to 'emonCMSlocal' buffer => time:<PHONE_NUMBER>.25, data: [10, 302, 0, 0, 0, 24253, 434, 634, 455, 665, 370], ref: 7585
2016-02-01 03:41:44,477 INFO emonCMSlocal sending: http://localhost/emoncms/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1454298104.25,10,302,0,0,0,24253,434,634,455,665,370]]&sentat=1454298104
2016-02-01 03:41:44,667 DEBUG emonCMSlocal acknowledged receipt with 'ok' from http://localhost/emoncms
2016-02-01 03:41:45,567 DEBUG emonCMS acknowledged receipt with 'ok' from http://emoncms.org
2016-02-01 03:41:45,580 DEBUG 7585 Append to 'emonCMS' buffer => time:<PHONE_NUMBER>.25, data: [10, 302, 0, 0, 0, 24253, 434, 634, 455, 665, 370], ref: 7585
2016-02-01 03:41:45,684 INFO emonCMS sending: http://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1454298104.25,10,302,0,0,0,24253,434,634,455,665,370]]&sentat=1454298105
2016-02-01 03:41:45,766 DEBUG emonCMS acknowledged receipt with 'ok' from http://emoncms.org
2016-02-01 08:08:19,343 DEBUG SIGINT received.
2016-02-01 08:09:09,476 INFO EmonHub Pre-Release Development Version (rc1.2)
2016-02-01 08:09:09,479 INFO Opening hub...
2016-02-01 08:09:09,492 INFO Logging level set to DEBUG
2016-02-01 08:09:09,495 INFO Creating EmonHubEmoncmsReporter 'emonCMS'
2016-02-01 08:09:09,512 INFO Set up reporter 'emonCMS' (buffer: memory | size: 1000)
2016-02-01 08:09:09,523 INFO Setting emonCMS url: http://emoncms.org
2016-02-01 08:09:09,525 INFO Setting emonCMS apikey: set
2016-02-01 08:09:09,528 INFO Creating EmonHubEmoncmsReporter 'emonCMSlocal'
2016-02-01 08:09:09,544 INFO Set up reporter 'emonCMSlocal' (buffer: memory | size: 1000)
2016-02-01 08:09:09,563 INFO Setting emonCMSlocal url: http://localhost/emoncms
2016-02-01 08:09:09,565 INFO Setting emonCMSlocal apikey: set
2016-02-01 08:09:09,568 INFO Creating EmonHubJeeInterfacer 'RFM2Pi'
2016-02-01 08:09:09,574 DEBUG Opening serial port: /dev/ttyAMA0 @ 9600 bits/s
2016-02-01 08:09:11,580 INFO RFM2Pi device firmware version & configuration: not available
2016-02-01 08:09:11,583 INFO Setting RFM2Pi frequency: 868 (8b)
2016-02-01 08:09:12,587 INFO Setting RFM2Pi group: 210 (210g)
2016-02-01 08:09:13,590 INFO Setting RFM2Pi quiet: 1 (1q)
2016-02-01 08:09:14,594 INFO Setting RFM2Pi baseid: 15 (15i)
2016-02-01 08:09:15,598 INFO Creating EmonHubSocketInterfacer 'Socket'
2016-02-01 08:09:15,601 DEBUG Opening socket on port 20100
2016-02-01 08:09:15,648 DEBUG RFM2Pi acknowledged command: > 8b
2016-02-01 08:09:16,154 DEBUG RFM2Pi acknowledged command: > 210g
2016-02-01 08:09:16,634 DEBUG RFM2Pi acknowledged command: > 1q
2016-02-01 08:09:16,900 DEBUG RFM2Pi acknowledged command: > 15i
2016-02-01 08:09:17,407 DEBUG 1 NEW FRAME :<PHONE_NUMBER>.41 10 244 3 0 0 0 0 0 0 204 94 69 1 81 1 68 1 176 2 19 2
2016-02-01 08:09:17,424 DEBUG 1 Timestamp :<PHONE_NUMBER>.41
2016-02-01 08:09:17,426 DEBUG 1 Node : 10
2016-02-01 08:09:17,429 DEBUG 1 Values : [1012, 0, 0, 0, 24268, 325, 337, 324, 688, 531]
2016-02-01 08:09:17,504 DEBUG 1 Append to 'emonCMS' buffer => time:<PHONE_NUMBER>.41, data: [10, 1012, 0, 0, 0, 24268, 325, 337, 324, 688, 531], ref: 1
2016-02-01 08:09:17,539 DEBUG 1 Append to 'emonCMSlocal' buffer => time:<PHONE_NUMBER>.41, data: [10, 1012, 0, 0, 0, 24268, 325, 337, 324, 688, 531], ref: 1
2016-02-01 08:09:17,607 INFO emonCMS sending: http://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1454314157.41,10,1012,0,0,0,24268,325,337,324,688,531]]&sentat=1454314157
2016-02-01 08:09:17,643 INFO emonCMSlocal sending: http://localhost/emoncms/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1454314157.41,10,1012,0,0,0,24268,325,337,324,688,531]]&sentat=1454314157
2016-02-01 08:09:17,852 DEBUG emonCMSlocal acknowledged receipt with 'ok' from http://localhost/emoncms
2016-02-01 08:09:18,116 DEBUG emonCMS acknowledged receipt with 'ok' from http://emoncms.org
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
I need to think about this some more, I can see no reason why if it is able to log the SIGINT why it isn't logging a graceful shutdown of emonhub. I need to find out some more info on Jessie and possibly why the SIGINT is being used over SIGTERM, and if that is a problem. I have no clue as to why this has suddenly changed, there has been no change to emonhub v1.2. Clutching at straws a bit here, but maybe the serial port not being gracefully closed is causing a serial communication error when trying to re-use the open but orphaned port and on this occasion it has eventually been closed by the OS prior to trying a restart on emonhub some 4+hrs later. I do not even know if the OS can do that, I'm just putting the clues together.
if it occurs again can you also do a "df -h" to check there is still some available disk space just in case it's choking?
Also can you set an "interval = 600" in the RFM2Pi runtimesettings, it will transmit the time for a glcd every 10mins, doesn't matter if you have one or not, it will cause emonhub to try and do something every 10mins even if theres no data coming in. I'm not suggesting this is the case but the log finishes quite tidily with an "ok" from emoncms as if it was patiently awaiting data from the rfm2pi for over 4hrs, the attempts to send the time would be proof of life and also the response to the attempts to tx the time will give insight to whether the rfm2pi is on-line.
Paul
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
Will do Paul. Will be good to get to the bottom of this.
One thing I did look at but when things were running again was to use top to see if anything is hogging the system. I think you had also seen some latency with SSH on Jessie. I'm not sure if I am reading the output correctly but the emonhub/emoncms bits seem to be taking less than 15% of CPU. So plenty of bandwidth there.
I'll report back if and when things go awry again.
Simon
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
@PB66 in case it affects your thinking my issue happened with EMONCMS locally and @Bramco appears to use emoncms.org so I'd guess that can be ruled out as a cause. I've just switched to a newly built image so it will be a few days before I can offer anything meaningful.
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
@sheppy. I use both. Local and .org.
Simon
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
@Simon. Presumably they both stop updating?
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
@Sheppy - yes it affects both of them.
Here's the output from the df -h
pi@Homepi-emoncms:~ $ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 5.1G 1.3G 3.6G 26% /
devtmpfs 87M 0 87M 0% /dev
tmpfs 91M 0 91M 0% /dev/shm
tmpfs 91M 4.5M 87M 5% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 91M 0 91M 0% /sys/fs/cgroup
/dev/mmcblk0p1 60M 20M 41M 34% /boot
Although I'm not sure I understand this as the system has been transferred to the HDD, so the sizes don't seem right.
Also attached is the emonhub log.
Take a look at 14:30 yesterday where I stopped and restarted the hub to add the interval = 600. This shows a normal stop and restart (unlike the one above, or the one at 08:22 today). Also from the log you can see that emonCMSLocal gets it's data in a big chunk every 10 minutes, which is I guess what you'd expect from the interval = 600 setting.
Everything seems to run normally like this, sending to emonCMS (.org) on every packet and to emonCMSLocal every 10 minutes until you get to 19:19 yesterday evening when the emonCMS sends stop and the new frame reporting stops. But sending to emonCMSLocal in 10 minute batches continues at 19:22 and then every 10 minutes until everything finally grinds to a stop at 20:23. (There does seem to be a disjoin between the last timestamp to emonCMS and the first time stamp in the next batch to emonCMSLocal.)
Anyway, over to you Paul, any ideas?
Simon
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
Although I'm not sure I understand this as the system has been transferred to the HDD, so the sizes don't seem right.
Have you expanded your filesystem to fill the HDD?
GParted is a good graphical tool to use, or it can be done using resize2fs via the command terminal.
Paul
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
Hadn't done that Paul, I was under the impression the script to switch from SD to HDD did that for you?
I'll use GParted next time I have to restart. Thanks for the tip.
Simon
PS If the script doesn't do the expand, maybe this tip should be added to the instructions for switching from SD to HDD.
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
The script does expand the filesystem, but in the HDD guide it stresses that it applies to systems installed via the Raspberry Pi installation guide, which is either Wheezy or Jessie, and I think that you are using Lite?
The script has not been tested using Lite, so probably doesn't work fully, as it relies upon other software being available in the OS, which maybe has been stripped out in Lite.
Paul
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
I'll give it a whirl later today when I'm home, I have the image saved so can quickly transfer it to an SD. I can't remember seeing any errors when I did it last time but if there are I'll post it in a separate issue.
Simon
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
@Simon - not quite sure how you ended up putting the "interval = 600" in the "emonCMSlocal" runtimesettings rather than the "RFM2Pi" runtimesettings but I believe it has proved the same point just not as cleanly or clearly.
Also you can set any runtimesettings without restarting emonhub, when you look at the log the "interval = 600" setting is acknowledged 15 secs before you restart emonhub. to see this in action open 2 ssh windows at once and run the command " tail -f /var/log/emonhub/emonhub.log in one and then in the other open emonhub.conf and edit some runtimesettings, each time you save the conf file the settings are picked up and applied to emonhub whilst running.
The addition of a "interval = 600" in the RFM2Pi runtimesettings as originally suggested may still shed a little more light if you wish to try that.
You could also remove the "interval = 600" from the "emonCMSlocal" runtimesettings, I recommend doing that as a separate "save" so the first action is easier to spot (this latter change will cause a rush in traffic to the local server as the restriction is lifted more on this below)
At 19:19:07 the last packet is processed from the rfm2pi, why that is the last packet I do not know at this point, perhaps an issue with the device, the serial port or indeed emonhub itself, however emonhub does continue to function as a backlog of packets has built up in the emonCMSLocal buffer due to the 10min posting rate set by the "interval = 600" and they continue to be delivered in batches of 100 every 10mins. However that continued delivery is in it's own child thread and the main parent thread may have stopped or is being blocked, I have never seen it occur and would not normally consider it an option but the lack of graceful shut down messages suggests emonhub has stopped, maybe.
Although at this point I do not think is is related and may even be detracting from the issue, but there are numerous "dns/dhcp type" error messages of more than one type, dotted throughout the log for both the local and remote emoncms connections. I know that's not something you want to hear but it is the case none the less.
I have attached your log with some notes throughout, it wasn't done in a way to publish it was just me adding markers whilst trying to decypher the info. If you use find or search in your text reader to search/find "????" all my comments start "????".
There are some "tracebacks" that look like a failure but they are have been caught and handled correctly, the traceback is provided in th e log for debugging only.
Originally I said this was unlikely to be the same issue as Sheppy's based on the few facts provided of which one was the "emonCMS timeout" error message you provided, I think ""those"" types of error message are unrelated to this issue and for the time being more likely to be just a characteristic of your setup.
What is the socket interfacer? the "sudo service emonhub status" log you provided seems to mention reading sockets but although I see one created in your log it doesn't seem to be used (in this log) is it worth disabling it for the moment if it's not being used? if so just add a "#" (hash) in front of the "Type = EmonHubSocketInterfacer" line in emonhub.conf, this has the effect of hiding the configuration from emonhub as every interfacer must have a Type and any that don't are ignored.
Please provide a new log of the error with the new settings and also the "sudo service emonhub status" mini log might be useful.
Paul
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
Paul,
Thanks for the clear explanations and apologies for putting the interval = 600 in the wrong place. Schoolboy error. I will rectify that and set things off again. I'll also comment out the socket interfacer, this is for my esp8266 Heat Bank controller which is reporting elsewhere until I get this thing going properly.
I can only see dns/dhcp type errors for the .org sends, all of only this type:
2016-02-03 09:02:16,066 WARNING emonCMS couldn't send to server, URLError: [Errno -2] Name or service not known
Am I missing something? We're with Virgin Media and their email was down yesterday so probably other things too which may have been causing these errors. And as you say are probably a DNS lookup problem and aren't detrimental to the whole as the next send works fine, so it's just a glitch which the code gets over.
Anyway, let's see if we get a log of a fail with the interval in the right place. Thanks again for taking the time to look at this.
Simon
PS Not sure if you've seen the jeelib weblog recently but there's a very interesting development from Jean-Claude Wippler around his Jet/Hub concept. You may want to take a look before embarking on the next version of emonhub.
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
@Paul Reed.
The USB HDD script worked fine on another system (Pi2) with a Jessie Lite image, so I'm not sure what happened on the PiB I'm running things on.
Next time I need to restart the system I'll check it out on the PiB although I can't see how the system should have any impact on the script.
Simon
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
Failed again Paul...
I'm going to try swapping the power supplies on the powered usb hub and the Pi to make sure it's not anything as daft as that. Can't see why it should cause any problems but you never know. I can also try running it just on the SD card.
pi@Homepi-emoncms:~ $ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 5.1G 1.3G 3.6G 26% /
devtmpfs 87M 0 87M 0% /dev
tmpfs 91M 0 91M 0% /dev/shm
tmpfs 91M 4.5M 87M 5% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 91M 0 91M 0% /sys/fs/cgroup
/dev/mmcblk0p1 60M 20M 41M 34% /boot
pi@Homepi-emoncms:~ $ sudo service emonhub status
● emonhub.service - LSB: Start/stop emonHub
Loaded: loaded (/etc/init.d/emonhub)
Active: active (running) since Fri 2016-02-05 09:35:28 GMT; 22h ago
Process: 6156 ExecStop=/etc/init.d/emonhub stop (code=exited, status=0/SUCCESS)
Process: 6197 ExecStart=/etc/init.d/emonhub start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/emonhub.service
└─6209 python /usr/share/emonhub/emonhub.py --logfile /var/log/emonhub/emonhub.log -...
Feb 05 09:35:28 Homepi-emoncms emonhub[6197]: Starting OpenEnergyMonitor emonHub: emonhub ha...ok.
Feb 05 09:35:28 Homepi-emoncms systemd[1]: Started LSB: Start/stop emonHub.
Hint: Some lines were ellipsized, use -l to show in full.
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
And again - from strange to weird.
Emonhub has managed to change my rfm12pi to 433 from 868Mhz which of course stops it receiving anything.
You can see in the attached log how first of all it stops receiving while this time the interval 600 keeps on working but then some spurious commands seem to go out to the rfm12pi which changes it's frequency.
df and status as below. (I did a sudo shutdown -r now after the first failure this morning.)
Simon
pi@Homepi-emoncms:~ $ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 5.1G 1.3G 3.6G 26% /
devtmpfs 87M 0 87M 0% /dev
tmpfs 91M 0 91M 0% /dev/shm
tmpfs 91M 4.5M 87M 5% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 91M 0 91M 0% /sys/fs/cgroup
/dev/mmcblk0p1 60M 20M 41M 34% /boot
pi@Homepi-emoncms:~ $ sudo service emonhub status
● emonhub.service - LSB: Start/stop emonHub
Loaded: loaded (/etc/init.d/emonhub)
Active: active (running) since Sat 2016-02-06 08:06:16 GMT; 3h 18min ago
Process: 330 ExecStart=/etc/init.d/emonhub start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/emonhub.service
└─372 python /usr/share/emonhub/emonhub.py --logfile /var/log/emonhub/emonhub.log --...
Feb 06 08:06:13 Homepi-emoncms emonhub[330]: Starting OpenEnergyMonitor emonHub: emonhub has...ok.
Feb 06 08:06:16 Homepi-emoncms systemd[1]: Started LSB: Start/stop emonHub.
Hint: Some lines were ellipsized, use -l to show in full.
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
"Emonhub has managed to change my rfm12pi to 433 from 868Mhz"
Where are you seeing this? do you have another log as your post suggests this has happened more than oncw this morning.
I see that 7:15 all still seemed well and another "normal" response was recieved by broadcasting the time
The "0s" command to send (with no request for an ack) the preceding csv (ie 0,7,15,0,) to node 0 (ie broadcast to all nodes) is acknowledged by the "> 0s" returned from the rfm2pi and the packet size was also confirmed in the following line with "-> 4 b" as 4 bytes correct for "0,7,15,0"
emonHub then continues to receive packets for the next 10mins until the last packet at 07:25:46, 6secs later it broadcasts the time at it's 10min interval (600s) all appears normally up to this point, But the response from the rfm2pi is very odd indeed. it acknowledges a command of "0b" 3 times, these responses are the only "bad" thing I can see besides the lack of received packets beyond this point. There are another 2 successfully sent and confirmed (both command and size) time broadcasts at 7:35 and 7:45. which suggests despite the lack of received packets, both the rfm2pi and emonhub "continue" to function.
I use the term continue but I cannot rule out the rfm2pi is restarting at some point. If there were a crash recovery and the eeprom stored config, freq, baseid and group were not available it would probally revert any unavailable settings to 433b, 15i or 210g as these are hard coded into the firmware. If we refer back to the "rfm2pi goes hard down" thread, only those users not sticking to the default 15i, 210g and 433b that get "changes" occuring and as I pointed out there, it is more likely the same thing is occuring to all users but it's undetectable on set-ups that stick to the defaults.
If the group, node or frequency were being changed and that was the cause of the original complaint then this could be proved by simply revising the settings in emonhub.conf, eg is you suspect the freq is wrong then change it to something other than what it should be, save the conf and then change it to what it should be again. emonhub will only send the "new" setting if there is a detected change in the conf file, so it must change to the correct setting to make emonhub reapply it.
Going back to what we see in emonhubs log the time is sent from emonhub via a hardcoded command that just has the hour and minutes values changed according to time so it is unlikely for that string to morph into something else to result in the 3 "0b" commands.
Even if the commas of the csv could be mistaken as "b"s by the rfm2pi there would be a 1 min window at midnight where all the values were "0" and even then there would probably be either 4 "0b"s or the 3 "0b"s would be followed by a broadcast transmission of "0" bytes.
Plus you are seeing an issue that was there prior to the "send time" code being activated so if this is a valid fault caused by the time sending then it is another issue on top of what you were already seeing.
Looking at the way the "b" command is processed in the current firmware, the "0b" commands would not result in any changes anyway. the "if(value)" would fail as the value is "0".
If emonhub was to change the frequency setting I would expect lines like this (taken from your previous log)
Right now I suspect the rfm2pi is at fault, although the evidence is far from conclusive, I was previously confident about emonHubs performance and less confident of any rfm2pi firmware, the clues we see do seem to fit that idea more than they cause me to question it.
The other log may show something different, or future logs may shed some light perhaps.
Would you consider installing a later firmware to the rfm69pi that you are not currently using???
We could write some extra logging into your emonhub to see exactly what is sent to the serial port at the time of the "send time" if we see this fail coincide with a send again but I do not feel that is the cause as it wasn't originally active.
Or add a line to emonhub to log everything received from the rfm2pi rather than discard anything not relevant to emonhub, but I feel these efforts would do very little even if they do reveal anything (and I'm not too sure they would) as we cannot change anything in the rfm2pi without uploading new firmware.
The systend mini log and the df -h do not show anything odd, in fact the systemd log seems to confirm there was no perceived issues during either the 22hrs or the 3hrs 18mins emonhub was running.
Sorry, I wish I could put my finger on the exact cause but currently the only smoking gun I see is the one used to put another hole in the messenger :-)
Paul
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
Hi Paul,
Apologies for the slow response. Life tries to continue even though my emoncms sysadmin work wants to take over. :-)
Anyway, where to start, I guess where you left off.... Smoking gun, I see no smoking guns around here... Sounds like the wide mouthed frog joke...
 I've attached the log again and leaving the interval timer running begins to shw some patterns.
Take a look at these extracts:
2016-02-07 22:48:24,049 DEBUG RFM2Pi broadcasting time: 22:48
2016-02-07 22:48:24,275 DEBUG RFM2Pi acknowledged command: > 22b
2016-02-07 22:58:27,321 DEBUG RFM2Pi acknowledged command: > 0b
2016-02-07 22:58:27,762 DEBUG RFM2Pi acknowledged command: > 58b
Fortunately the rfm12 has at some stage been switched to 433, so the log isn't cluttered with received buffers as it's long since given up the ghost on that front.
In the log, the 1st failure happens around 9:59 yesterday with the 0bs and 0ss and after that I did a sudo shutdown -r.
At 13:07 it goes again and you can see the rfm12 responses start to match parts of the time and packets stop, so somehow the rfm12 has reverted to 433MHz
Then you get this sequence, which shows the rfm12 acking an 8b command and obviously reverting to 868MHz as packets start to arrive 5 seconds later.
2016-02-07 18:08:21,477 DEBUG RFM2Pi acknowledged command: > 8b
2016-02-07 18:08:25,014 DEBUG 709 NEW FRAME :<PHONE_NUMBER>.01 10 197 8 0 0 0 0 0 0 231 93 210 1 132 2 210 1 166 2 119 1
And then 10 minutes later it goes again, although this time we see a 1b command which will change the band although it's not a valid b command.
2016-02-07 18:18:10,175 DEBUG emonCMS acknowledged receipt with 'ok' from http://emoncms.org
2016-02-07 18:18:21,282 DEBUG RFM2Pi broadcasting time: 18:18
2016-02-07 18:18:21,504 DEBUG RFM2Pi acknowledged command: > 1b
2016-02-07 18:18:21,946 DEBUG RFM2Pi acknowledged command: > 0b
2016-02-07 18:28:21,355 DEBUG RFM2Pi broadcasting time: 18:28
2016-02-07 18:28:21,577 DEBUG RFM2Pi acknowledged command: > 0s
2016-02-07 18:28:21,799 DEBUG RFM2Pi confirmed sent packet size: -> 4 b
So all told I'm not sure I'm any clearer, except in this log we've seen some reasons as to why the rfm12 changes band.
Following on from what you said in your earlier analysis, I guess it could be that the rfm12 is restarting but somehow with the various b commands being received, I'm not sure about this. Doesn't the rfm12 store the settings in EEPROM? And if so wouldn't it simply restart in 868.
Or is all of this just some flaky connection or power supply. I did swap the power supply a few days ago when I moved the system onto my work bench, maybe I'll try the cable and a different usb hub to see if it is down to the those types of issues.
Smoking guns, anyone seen any smoking guns? :-)
Simon
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
Ok this log has far more interesting bits. I can see some of the time updates do result in incorrect acknowledgements, where it could be tripping up isn't really clear, is emonhub sending the correct packet? is the packet arriving intact at the rfm2pi? or is the rfm2pi misinterpreting the packet?
The time sends themselves cannot be the root of the issue, as previously pointed out your issue pre-dates the activation of the time sending code and the time send packet is hardcoded so that only the hours and minutes values are changed, the csv commas and the trailing s command are fixed in the write to serial port code.
There are many instances that do not make any sense, to point where the responses may just be garbage without an obvious pattern. I have studied alot of emonhub.logs for many reasons as you can imagine and I have never seen "rogue acknowledgements", given I wasn't looking for them I cannot say they do not exist but I would have certainly expected to have noted some along the way.
I can see from the help-text and current configuration text blocks that the frequency has been changed to 433, but at no time was there a logged "4b" command nor an acknowledgement to that effect, there are many, many "0b"s and some "1b"s and although they may not show the command being sent the commands are acknowledged, so why not the "4b" even the "8b"s are always acknowledged.
There are instances where the time is sent and the minutes OR the hours get morphed into a b command, but never both, why do some get morphed into 4 x "0b"s ? ie what happened to BOTH the time values.
There is an instance where "0i" is set, this is an issue that was fixed in the last commit to the oem rfm2pi firmware, that causes a "failed configuration" and will not recover untill a valid node id is set (1 to 30), or a reboot/crash forces the use of eeprom values.
You comment above about the settings being stored in the eeprom is correct, IF that is functioning correctly that is what is supposed to happen, as you'll see in the other thread there is a question over the rfm2pi forgetting it's config and reverting to the hardcoded values, highlighted by Glyn using a version that did not store it's config to the eeprom.
The help text for your device clearly states <nnn>g will set the group but looking closer at your logs the 210g command never works, nor does the "q" but that was absent from some firmwares.
Looking back at your first "600" log there is an instant where at 8:23 3rd feb the group and quiet commands are sent
2016-02-03 08:23:22,242 INFO Setting RFM2Pi group: 210 (210g)
2016-02-03 08:23:23,246 INFO Setting RFM2Pi quiet: 1 (1q)
and they are somehow morphed into one
2016-02-03 08:23:29,763 DEBUG RFM2Pi acknowledged command: > 211q
This is when the interval = 600 was in the reporter so there was no time sending, but the way emonhub processes settings in a loop it uses a fixed pattern to write to the serial port with only the command in the brackets inserted and sent each loop before it reads the next setting. At the other end in the rfm2pi firmware each char is processed individually and any "command character" can trigger the processing of a command using the previous value(s). eg 8b is a "b" command and the last value was 8 so "8b" it is.
This leads me to believe the rfm2pi had taken the leading "21" of the "210g" and not seen or ignored the rest until the "1q" arrived making the command "211q", whether that is a serial issue or a firmware issue or an hardware issue I couldn't say based on what we have.
There also seems to be alot of coincidence suggesting reuse of variables perhaps, why do the time sends result mainly in "b"s and occasionally an "i"? why any other command character eg "a"?
I do not see enough of a pattern to determine the cause. Unless you can monitor the serial traffic somehow you need to change one end or the other to move forward, v1.2 emonhub is being used reliably on many systems and is less likely to be the cause based on the little evidence we have. Your rfm2pi is running an unknown out of date firmware that may (or may not) be the cause.
You have a spare device and the quickest and most sensible test you can do right now is to load the firmware that Paul Reed is testing for a similar issue, see "Feeds stop updating" and try that before anything else. the data we are gathering seems too random to be of use and if it does turn out to be a problem with a firmware that should be out of service then we have all wasted out time.
I am not saying it is definitely the rfm2pi firmware, nor am I saying the firmware Paul is testing will fix it. But there is a long standing issue with a number of rfm2pi's that predates your setup and emonhub so it would seem the best place to start is there unless there is evidence to suggest something different to tackle.
It could possibly be power related I guess, but since the Pi is more power hungry and less "single minded" than the AVR I would of expected trouble to manifest in other ways too, but I suppose it also depends on how robust the hardware is to low voltage? It may also be a "Jessie" or "Jessie-lite" issue as these are still relatively new ventures and may require "tweeks" to the way we have been doing things in wheezy, including emonhub. And yes it could be an emonhub issue too which I would be very keen to resolve if it turns out to be the case.
Paul
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
Hi Paul,
Yes I can bet you've seen your share of emonhub logs in your time!
I think we can rule out power supply issues as I swapped out both supplies (Pi and USB hub) and it's still failing.
I've been watching the other thread with interest and will try updating the firmware as outlined there. I'll let you know if there is any progress. Might try it on the spare rfm69 as you suggested earlier.
Simon
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
Yes if you are tempted to try the firmware update then I would recommend the rfm69pi, it's not in service so you can swap it in and then out again if it's worse, leaving your existing rfm12 rfm2pi as it is until we are a little more sure of the situation means you have little to lose by trying the later firmware.
The hex file attached to that thread is compiled for a rfm69 so it will not run on your rfm12 device, I can recompile for a rfm12 no problem but it would be better at this stage if all testing was done with a common hardware/firmware combo.
Paul
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
So more than a week later and with the rfm69 in place and updated to the firmware Paul provided in this thread everything is running fine. So I think my issues must have been down to a failing rfm12 (hardware).
Thought I'd give this thread a jog as I noticed Paul (Reed) had had another failure.
For the record my system is a PiB with Jessie Lite running on a USB HDD and an rfm69 running the firmware above.
Simon
PS - I've also rebooted my router a couple of times in the last week and Jessie Lite hasn't had any problems in reconnecting (Edimax dongle).
PPS Thanks to Paul as usual for the patience and taking the trouble to make the latest firmware for the rfm.
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
This is good news Simon.
Regarding your other rfm2pi, it may well be a firmware issue not a hardware issue, can you confirm it is definitely a v2 not a v1 (I'm sure we've done this but I want to be sure) ie it is a small surface mount mcu not a big 28 pin DIL ?
I can recompile the firmware for you to use on a rfm12b RFM2Pi v2 very easily, I have only refrained from doing so only to avoid confusion since we are only currently focusing on debugging the rfm69, perhaps we can try that down the line once the firmware is a little more tried and (time)tested, so don't give up on or bin the rfm12 device just yet.
Paul
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
Hi Paul, was beginning to worry about your health! A week away, must have been vacation :-)
As for the rfm12 it's a V2.5.3 with the surface mount. I'd be glad to test it again with revised firmware although of course the system is running like a train at the mo' (fingers crossed of course) so maybe it would be worth waiting to see if it fails again. And as you imply fixing the 69 versions is much more important as the 12s are not being supplied any more.
Simon
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
"vacation" no such luck! Just very, very busy with a work project at the moment, lots of very long days, my sanity is as much a concern as my health right now :-) But thanks for your thoughts :-)
I didn't intend to imply rfm69 was more important, just that there are more active "69" complainers ie testers and not complicating the issue with 2 different rfm modules seemed the wiser option, lets stick with "69" now for simplicity and then if/when fixed we can roll out to rfm12, these are perhaps the devices that will most need the updated firmware as they are further behind.
I have an almost finished script that will be incorporated into emonhub to "watch" a firmware repo (local or remote) and if the "version" increases it will update the rfm2pi automatically, it does not require the use of the "avrdude-rpi" mods it all done in-house by emonhub. I would hope to roll this out to all emonhub + rfm2pi users regardless of vintage of device to activate the code the user would just need to define the device ie 12 or 69 in emonhub.conf.
This paves the way for a closer emonhub to rfm2pi integration as I am also working on "fault codes" as a shorthand way for the rfm2pi to communicate it's status or events to emonhub which will in turn react or at least log them in user friendly long hand messages.
Paul
Re: Emonpi image, RFM69PI images froze, rest of Emonhub MQTT inputs still ok
Sounds like a good plan Paul. The more these things can be automated and provide sensible long hand messages the better.
In the long term I'm planning to move away from rfm and onto wifi based systems (esp8266). My Heat Bank and CH controller (esp8266) now monitors all the temperature sensors, so the emonTx is only managing the PV diversion and reporting the power. As soon as I have that set up to manage the boiler properly with weather compensation etc. via node-red and MQTT, I'll be trying to build a replacement for the emonTx based on an esp8266 using an external ADC chip to start with.
Simon


“Only one who devotes himself to a cause with his whole strength and soul can be a true master. For this reason mastery demands all of a person.” – Albert Einstein
Very often you’ll see blog posts or books teaching you to “master” a skill in only 10 days, or 3 days … in fact, it used to be 30 days but the time frame to master something seems to be shrinking rapidly.
I’ve even seen tutorials claiming to teach a skill in just a few hours. Pretty soon we’ll be demanding to know how to do something in seconds.
Instant mastery of skills and knowledge! Hey presto!
Unfortunately, the reality is something a little less magical. Or maybe that’s a fortunate thing.
There’s only one way to become good at something:
1. First, you must learn it by reading or listening to others who know how to do it, but most especially by doing.
2. Then do some more. At this point, you’ll start to understand it, but you’ll suck. This stage could take months.
3. Do some more. After a couple of years, you’ll get good at it.
4. Do some more. If you learn from mistakes, and aren’t afraid to make mistakes in the first place, you’ll go from good to great.
It takes anywhere from 6-10 years to get great at something, depending on how often and how much you do it. Some estimate that it takes 10,000 hours to master something, but I think it varies from person to person and depends on the skill and other factors.
Want to be a great writer? It’s possible to be great within a few years, if you have the God-given talent of Fitzgerald or Shakespeare, but most of us toil for over a decade and are still trying to get better. We’re still learning, to this day, and if we look back on our first few years of writing — of any kind — we’ll tell you we sucked (for the most part) back then.
Want to be a great blogger? Same deal. I’ve been doing it for almost three years, and I’m still only competent. Gruber’s been doing it for, like, 7 years and he’s still only … well, he’s pretty great by now. You have to do it, make mistakes, learn, really begin to understand it, and someday, if you stick with it, you’ll be great.
There’s no one who is great at his profession who hasn’t been doing it for at least 6 years — no designer, no programmer, no carpenter, no architect, no surgeon, no teacher, no musician, no artist … you get the point.  Most have been doing it for over a decade, and are still looking to improve.
It takes desire, it takes drive, it takes lots and lots of doing.
So here’s the thing: don’t get discouraged if you’re just starting out. Have fun, like we all did in the beginning. If you have fun, you’ll learn to love it, and THAT’S when it clicks. When you love something, you’ll want to do it all the time, sometimes late at night and often, you’ll jump out of bed and want to do it before you move your morning bowels.
THAT’S how you get great. By loving it so much your morning bowel movement takes second seat.
“Everybody has talent, it’s just a matter of moving around until you’ve discovered what it is.” – George Lucas
Find that desire. Do it, don’t just read about it. Don’t buy a single product or book or magazine that claims to teach you something in minutes, hours, days. They’re lying to your face, with a hand in your pocket at the same time.
Do it, keep doing it, then keep doing it some more. It’s the only way to get great, but the good news: anyone can do it. It just takes some time and some doing. Hey presto.
When the world says, “Give up,”
Hope whispers, “Try it one more time.”
~Author Unknown
Posted with :


This is the API
http://petstore.swagger.io/v2/pet
PUT
Pet object that needs to be added to the store
http://petstore.swagger.io/v2/pet
POST
Pet object that needs to be added to the store
Multiple status values can be provided with comma seperated strings
http://petstore.swagger.io/v2/pet/findByStatus
GET
Status values that need to be considered for filter
Muliple tags can be provided with comma seperated strings. Use tag1, tag2, tag3 for testing.
http://petstore.swagger.io/v2/pet/findByTags
GET
Tags to filter by
Returns a pet when ID < 10. ID > 10 or nonintegers will simulate API error conditions
http://petstore.swagger.io/v2/pet/{petId}
GET
ID of pet that needs to be fetched
http://petstore.swagger.io/v2/pet/{petId}
POST
ID of pet that needs to be updated
Updated name of the pet
Updated status of the pet
http://petstore.swagger.io/v2/pet/{petId}
DELETE
Pet id to delete
http://petstore.swagger.io/v2/pet/{petId}/uploadImage
POST
ID of pet to update
Additional data to pass to server
file to upload


mxnet
Main Page
Related Pages
Modules
Namespaces
Classes
Files
Modules
Here is a list of all modules:
[detail level
1
2
3
4
]
▼
C API
▼
Primitive operations
Common primitive operations
▼
Attributes
Sequence of post operations
Memory
Reorder
Concat
Sum
Convolution
Deconvolution
Shuffle
Eltwise
Softmax
Pooling
LRN
Batch Normalization
Inner product
RNN
Engine operations
Execution stream operations
Service functions
BLAS functions
▼
Types
Generic
▼
Auxiliary types for memory description
Operation descriptors
Engine
Primitive descriptor iterators
Primitive descriptors
Primitive descriptor attributes
Primitive
Queries
Execution stream
Generated on Wed Jul 31 2019 01:36:58 for mxnet by
1.8.11


@* Copyright 2018, Oath Inc.
Licensed under the terms of the Apache License 2.0. Please see LICENSE file in project root for terms. *@
@(lookupsMap: Map[String, List[(String, String, String, String, String)]], tierLookupConfigMap: Map[String, List[(String, String)]])


A list of things that you have achieved today
Note: The data isn't stored, so it will disappear if you reload!


Faculty Details
more_vert
remove
fullscreen
Name
14PEB049
Faculty Member
Male
Active
check
×
×
Fix this and try and try again
Department
Gender
Unspecified
Name
Designation
Working
Account Enabled
2 Factor Authentication
Email
Phone Numbers
Edit Roles
check
Update
No such faculty member found


Amazing people are making amazing designs in a fun enviroment
When you work with us, you are part of a team of committed collaborators. All aspects of our software development process are intergrated, interactive and agile.
Our approach unifies design, development and product management: to create exceptional products.
We start each project by understanding your business goals, the user's needs and the product requirements
Then we help translate them into effective and elegant solutions
Our design practice offers a full range of services including brand strategy, interaction and visual design
and user experience testing.
Throughout your project, our designers create and implement visual design and workflows, solicit user
feedback and work with you to make sure what gets built is what is needed.
All engineers are fluent in the latest enterprise, mobile and web development technologies.
They collaborate with your team to write, and improve code on a daily basis, using proven practices such as
test-driven development and pair programming.
Planning and development is iterative. Because we are constantly coding and testing, the products we build
are always ready to go live.
This iterative process allows for changes as business requirements evolve.


WITNESS LIST
Finance
July 2, 2013 9:00 AM
FOR:
Guzman, Crespin Association Administrator (also providing written testimony) (Texas
Section - American Society of Civil Engineers), Austin, TX
Registering, but not testifying:
FOR:
Aghamalian, Brandon Consultant (City of Galveston), Austin
Aghamalian, Brandon Consultant (City of Southlake)
Aghamalian, Brandon Consultant (City of Sugar Land), Austin, TX
Allison, Jim General Counsel (County Judges & Commissioners Assn. of TX), Austin, TX
Bushell, Gary Attorney (Alliance I-69 Texas), Austin, TX
Bushell, Gary Attorney (US 190 Gulf Coast Strategy Highway), Austin, TX
Carr, Snapper Attorney (City of Denton), Austin
Carr, Snapper Attorney (Andrews County), Austin
Cassidy, Brian Attorney (Alamo RMA, Camino Red RMA, Cameron County RMA,
Central Texas RMA, Grayson County RMA, North East Texas RMA), Austin, TX
Claunch, Dave Mayor (City of West Lake Hills), West Lake Hills, TX
Findeisen, Les Director of Policy (Texas Motor Transportation Association), Austin, TX
Foreman, Mike City Manager (City of Celina)
Hammond, Bill President (TX Association of Business), Austin, TX
Hart, Tom City Manager (City of Grand Prairie), Grand Prairie, TX
Janes, Brandon Attorney (Transportation Advocates of Texas), Austin, TX
Kearns, Dennis Attorney (BNSF Railway)
Lee, Donald Executive Director (Texas Conference of Urban Counties), Austin, TX
McKnight, Peyton General Counsel/Legislative Director (American Council of
Engineering Companies of Texas), Austin, TX
Mendez, Mark Assistant County Administrator - Gov. Affairs (Tarrant County), Ft. Worth,
TX
Miranda, Eddie Public Policy Manager (Greater Houston Partnership), Houston
Munoz, Ned General Counsel (Texas Association of Builders), Austin
Newton, Jennifer Director, Public Affairs (AGC of Texas), Austin
Norman, Scott Executive Director (Texas Association of Builders), Austin, TX
Olson, Lawrence (TX Good Roads Assn.), Austin
Patterson, T.J. (City of Fort Worth), Ft. Worth
Perez, Richard President/CEO (Metro 8 Chambers of Commerce), San Antonio, TX
Ray, Beth Ann Vice President, Regional Infrastructure (Austin Chamber of Commerce),
Austin
Shields, Chris Lobbyist (San Antonio Mobility Coalition), ATX
Shields, Chris Lobbyist (The Greater San Antonio Chamber of Commerce), ATX
Shields, Chris Lobbyist (Fort Worth Transit Authority), Austin, TX
Snowden, Tara (Zachry Construction Corp.), SA, TX
Tagliabue, Tom Director of IGR (City of Corpus Christi), Corpus Christi
WITNESS LIST
Finance
July 2, 2013 9:00 AM
AGAINST:
Villanueva, Chandra Policy Analyst (Center for Public Policy Priorities), Austin, TX
ON:
Bass, James Chief Financial Officer (TxDot)
Providing written testimony:
AGAINST:
Hartman, Eric Director of Government Relations (Texas AFT), Austin, TX


Upload upto 4 image files from local machine, webcam, or use sample images
RESULTS
Object Detection
Object Detection
Object Detection
Object Detection
RESULTS
Object Detection
Image Classification
Image Similarity
RESULTS
Upload upto 4 image files from local machine, webcam, or use sample images
RESULTS
Object Detection
Object Detection
Object Detection
Object Detection
RESULTS
Object Detection
Image Classification
Image Similarity


List of Accounts
Accounts
Select account
Admin
Customer
Account Settings
Account Name
Account Email
Password
Re-enter Password
Phone
Address
Update Infomation
Delete Account


Hi Sir/Madam,
Thank you for your interest in RampRate! You will receive an email from ramprate.com with a link to this resource.
If you do not receive the email within several minutes, please check your junk email folder or spam filter. If you need assistance, please send an email to marketing@ramprate.com.


Two new phones — the Pixel 4 and iPhone 11 — but which is for you?
Pure Google
Pixel 4
Powerful and affordable
iPhone 11
The Pixel 4 is Google's model for what Android should be: fast, fluid, and with great imaging. Its cameras take fantastic photos in any lighting conditions, and with astrophotography mode you can even capture the stars. However, battery life and pricing don't do the phone any favors.
Pros
- Stellar astrophotography mode
- 90Hz display
- Android 10 with fast updates
- Face Unlock even faster than Face ID
Cons
- Poor battery life
- No ultra-wide camera
- More expensive
The iPhone 11 packs Apple's most powerful processor and two fantastic cameras into its most affordable phone of the year. It's a bit on the large side, but its ultra-wide lens is more useful than a telephoto sensor, and it shoots great-looking 4K60 video.
Pros
- Fantastic battery life
- Works well with other Apple devices
- Smooth video recording
- Excellent battery life
Cons
- Low-res display
- No telephoto camera
- Less customizable software
There are seemingly endless options for phones from different manufacturers these days, but if you're after the best possible software experience, why not buy directly from the maker of the operating system? Google and Apple both have fantastic offerings this year, but while they look similar in hardware, there's a lot that's different between the Pixel 4 and iPhone 11. Assuming you're relatively platform agnostic, which should you buy?
Clean software and night vision cameras
Source: Hayato Huseman / Android Central
Physically, it's no stretch to say that the Pixel 4 and iPhone 11 look similar, at least from the back. Both phones feature a glass and metal construction with square housings for their dual camera modules and matte-finish side rails for extra grip. While the iPhone 11 is only available with a slick glossy backing, only the black Pixel 4 is glossy, with the white and orange models featuring frosted glass instead. Build quality on each phone is outstanding, and both feature wireless charging and IP68 water and dust resistance.
Around the front, the differences are more apparent. The iPhone 11 has the same wide display notch up top that Apple's been using since the iPhone X, housing the necessary sensors for its Face ID authentication, while the PIxel 4 sticks with a more traditional "forehead" bezel above its display.
Both phones are incredibly well-built, but the Pixel 4's sharper, faster 90Hz display is a nice perk.
New this year for the Pixel is a combination of radar and infrared sensors that enable its own Face Unlock system in lieu of a fingerprint sensor, which works incredibly well and is even faster than Face ID, but with far less support. We're still waiting on Android developers to adopt Google's new biometrics API that enables Face Unlock for signing into apps.
You'll get a larger display with the iPhone 11, a 6.1-inch LCD panel versus the Pixel 4's 5.7-inch P-OLED, but the latter is both higher resolution and faster with a variable refresh rate at up to 90Hz. This plays a big role in making the PIxel 4 feel speedier when scrolling around in apps, but both phones are incredibly responsive.
| Category | Pixel 4 | iPhone 11 |
|---|---|---|
| Operating System | Android 10 | iOS 13 |
| Display | 5.7 inches, 19:9 aspect ratio, 2280 x 1080 (444 ppi) resolution, P-OLED | 6.1 inches, 19.5:9 aspect ratio, 1792x828 (326 ppi) resolution, LCD |
| Processor | Snapdragon 855, 8-core, 2.84GHz | A13 Bionic, 6-core, 2.65GHz |
| Graphics | Adreno 640 | Apple GPU |
| Memory | 6GB | 4GB |
| Storage | 64/128GB | 64/128/256GB |
| Expandable Storage | No | No |
| Rear Camera | 12.2MP, ƒ/1.7, 28mm + 16MP, ƒ/2.4, 45mm | 12MP, ƒ/1.8, 26mm + 12MP, ƒ/2.4, 13mm |
| Front Camera | 8MP, ƒ/2.0, 22mm | 12MP, ƒ/2.2, 23mm |
| Security | Face Unlock | Face ID |
| Ports | USB-C | Lightning |
| Audio | Earpiece + loudspeaker | Earpiece + loudspeaker |
| Battery | 2800mAh | 3110mAh |
| Water Resistance | IP68 | IP68 |
| Dimensions | 147.1 x 68.8 x 8.2mm | 150.9 x 75.7 x 8.3mm |
| Weight | 162g | 194g |
| Colors | Just Black, Clearly White, Oh So Orange | White, Black, Green, Yellow, Purple, Red |
Source: Hayato Huseman / Android Central
On the software side, both Android 10 and iOS 13 have a lot of pros and cons, but they're undoubtedly the best iterations of their respective platforms. In Android 10, you get a system-wide dark mode along with, among other things, useful features like live transcription of any audio (great for loud environments or for those who are hard of hearing), call screening to field potential spam calls, and completely revamped privacy and security measures.
In iOS 13, you won't get as much customization as on Android, but in exchange you're getting the keys to Apple's diverse ecosystem; you'll get iMessage for easily communicating with other iPhone owners, Airdrop for wirelessly transferring files to other Apple devices (including Mac computers), and a wider variety of high-quality apps through the App Store. You also gain access to the unmatched Apple Watch, which could be almost as big of a selling point as the phone itself if you're a smartwatch fan.
Cameras are a huge toss-up here, since the Pixel 4 and iPhone 11 both feature some of the best cameras of any phones on the market. The main sensors are pretty evenly matched, but the secondary lenses take completely different approaches; the Pixel 4 has a 2X telephoto lens, while the iPhone 11 opts for an ultra-wide. If you ask me, the latter is much more useful, especially since telephoto can be closely replicated with digital zoom and computational data (Google even uses this approach to achieve cleaner zoomed images up to 8X), but that's a matter of personal preference.
Astrophotography on the Pixel 4 pulls off miraculous star photos.
Both phones also feature incredibly impressive low light shooting modes that let you capture photos at night, and they look brighter than even your eyes can see. The Pixel's Night Sight has been the largely undisputed champion of low light photography since the feature's unveiling with last year's Pixel 3, but the iPhone 11 gives it some very close competition, and edges out in some instances. Check out our deep dive comparison to see for yourself.
Where the Pixel really wins out is in its new astrophotography mode, which uses a combination of Night Sight, HDR+, and what Google calls Semantic Segmentation to pull off shockingly detailed and clean images of the night sky. The iPhone 11 has an astrophotography mode of its own, but it's not nearly as complex, essentially boiling down to a simple long exposure.
The iPhone 11 is cheaper, shoots better video, and lasts much longer.
Though the iPhone does now benefit from Apple's Deep Fusion technology, which, like Semantic Segmentation, uses computational data to identify different objects within the frame of your shot and process them individually, sharpening fine details like facial hair without affecting the rest of the image. It's also able to shoot in 4K at up to 60 frames per second (FPS) on both of its rear cameras and even the front camera; meanwhile, the Pixel 4 maxes out at 4K30, with the front camera reducing down to 1080p30.
Source: Android Central
Some simpler details to wrap things up: While both phones start at a measly 64GB, the Pixel 4 can only be upgraded to 128GB, while the iPhone 11 can go a step up to 256GB — all while starting off at $100 less than the Pixel. The iPhone 11 also has dramatically better battery life. Whether you want to credit the 11% larger battery, iOS's better power management, or the lower resolution display, the iPhone 11 can last up to two days on a single charge. The Pixel 4, however, struggles to make it through a single day with even light usage.
Those factors alone may be enough to sway you into buying the iPhone, but of course there are plenty of other variables to consider. You may prefer the Pixel 4's imaging, particularly its astrophotography capabilities, or simply prefer Android over iOS — or maybe you just like having a smaller phone.
For most people, though, the iPhone 11 is a better deal if you're looking purely from a value perspective and don't have any reservations against iOS. Video recording is much better on the iPhone, and unless you value the Pixel 4's astrophotography, the iPhone's ultra-wide camera is largely more useful than the Pixel's telephoto and you'll be just as happy with the primary sensor.
Pure Google
Pixel 4
Android 10 and cameras that can see the stars.
The Pixel 4 is Google's model for what Android should be: fast, fluid, and with great imaging. Its cameras take fantastic photos in any lighting conditions, and with astrophotography mode you can even capture the stars — but battery life and pricing don't do the phone any favors.
Powerful and affordable
iPhone 11
Apple's cheapest phone is incredibly well-versed.
The iPhone 11 packs Apple's most powerful processor and two fantastic cameras into its most affordable phone of the year. It's a bit on the large side, but its ultra-wide lens is more useful than a telephoto sensor, and it shoots great-looking 4K60 video.
We may earn a commission for purchases using our links. Learn more.


Solutions for toddlers 4months to 2 years
- ‘Normal babies sleep through the night’ is an exception to the rule.
- If you are to help your baby sleep all night then you will have to force yourself to stick to your plan, even if it’s the 5 time you have attended to him
- Tell yourself in these scenarios ‘in a month or two your baby will be sleeping all night’
- Sugar (cookies, chocolate) just isn’t good for late in the day.
- Baby maybe me hanging on to night feeds during day as comfort. You and baby time. May have to give more cuddles etc during day to help her adjust.
Bedtime routine
- Hour before bed should be very relaxing dim lights
- Last step should end in the bedroom with very little chat and usual go to sleep technique
- Follow your exact routine every night, however if you notice if notice your child is yawning fussing skip bath and books etc and get him to bed asap.
- Establish early bed time routine. 6:30/7pm
- Also get up at the same time every morning will help babies biological clock.
- Naps help babies sleep during the night, should be between 1-2 hours. If waking after 30 mins, try go into him as soon as you hear murmurs and try and get him back to sleep.
- Early afternoon nap is best for sebastian 12-2, try and be consistent, watch for signs as child might get a second wind.
- Develop and keep a standard nap routine, a well rested baby can handle different sleep ideas in the evening better.
Learn how to make your baby fall asleep by himself
- ‘My bed is a nice place’ - need to know that their bed is a safe and secure place.
- Spend some time in the cot during the day playing with toys etc so that he gets to associate it as a nice place, if he responds positively to this try and get him playing with a toy as you fade away and watch him beside the cot
- Falling asleep in more than one way. Try to establish more. Currently sebastian falls asleep on mattress after bottle and then put him into cot. I have been putting him on the mattress but into the cot before he nods off so he is not as surprised when he wakes up, in fact the plan is that he find comfort waking there and should go back to sleep easier - and more importantly, on his own.
- Use a toy, not to take your place but to give some comfort in your absence
- Place him in between the two of you whenever you feed
- When baby wakes during night, do not talk to him other then the sleep cues, ie ssh and nighty night etc. do not turn lights on, affect his biological clock.
- Sleep cues, once you decide on them only use then when your baby is tired sleepy and relaxed. Do not use them when crying etc.
- You can use white noise as a sleep cue also.
- She noted, the way in which our baby falls asleep for the night is how he expects to remain all night long.
- Pulling hair to go to sleep, try Pantleys gentle removal plan. Let him grab your hair, but try to put teddy between you.  He will root for your hair, but try and use teddy, eventually he will want your hair again, repeat but take away again and replace with teddy. It might take 10 times initially. But should go down over time, and awakenings should lessen.
Breastfeeding to sleep
- Problem is that baby thinks it’s the only way to fall asleep.
- When you are sure your baby is awake and looking to nurse, go ahead and nurse him for a short time. Stay awake! And as soon as he slows his pace from the gulping, drinking mode to the slow fluttery comfort nursing, you can gently disengage him while patting him or rubbing him. (See Pantley’s Gentle Removal Plan above)
- If your baby whimpers at any point during this removal process, or somehow lets you know he is up for real (by crawling onto your chest, for example!), go ahead and breastfeed him. Then repeat the process to keep the nursing session short, and disconnect him before he is deeply asleep.


@()
Kurator provides scientific workflow tools for data quality improvement of natural history collections and other biodiversity data. Kurator Web is a set of a user friendly web interface to configure and launch curation workflows while maintaining provenance. Kurator-Akka and the Kurator YesWorkflow data curation software and code are available on GitHub.
For more information about Kurator, please visit our wiki or watch an introductory video (https://vimeo.com/274087877)
Aggregates two files into one file.
Creates a report of counts of distinct geographic values and provides recommended values.
Creates a new file with as many field names standardized to Darwin Core as possible.
Validates event date fields and fills in missing dates from atomic event date fields.
Creates a report of counts of distinct values and recommended values for values that are not standard.
Creates a new occurrences file with standardized geography and original geography saved in new fields.
Performs validation of the georeference fields and fills in or transposes missing or inconsistent coordinates.
Parses "dynamicProperties" field in a DarwinCore-Archive spreadsheet and creates separate fields for each value.
Creates file containing the recommendations to standardize distinct combinations of higher geography.
Creates a vocabulary file with fields for the original values, the standard values, and vetted values.
The Kurator project is a collaborative project led by The University of Illinois Urbana Champaign and Harvard University and other partners and funded by the National Science Foundation. Learn more about the project here (link to: http://wiki.datakurator.org/wiki. Kurator: A Provenance-enabled Workflow Platform and Toolkit to Curate Biodiversity Data Collaborative NSF Awards 1356438 and 1356751


Check the roommates that will participate in the bill. By default the bill will be split evenly amongst the participating roommates. If you would like change the percentage each roommate pays then place the number of percent
they will pay in their respective box. All boxes must equal 100.


IRS Voices Concerns Over Crypto Kiosks and ATMs
by Ali RazaThe IRS has announced that it is investigating crypto kiosks and ATMs with concerns regarding tax evasions, as well as the possibility of money laundering, controlled substance purchase, and similar crimes.
Crypto ATMs and kiosks have become an increasingly popular method of purchasing cryptocurrencies, as well as withdrawing funds among the United States-based crypto users. However, according to a recent Bloomberg interview, the IRS has raised concerns over potential tax evasion issues that might arise from the increased use of the machines.
The IRS concerns
The problem lies in the fact that anyone can walk up to one of crypto ATMs or kiosks, deposit cash and receive BTC. Naturally, the IRS would like to know who these users are, what are their goals, where does their money come from, and so on. However, they are also interested in the owners of the kiosks, who are making money by offering their devices to the public.
They’re required to abide by the same know-your-customer, anti-money laundering regulations, and we believe some have varying levels of adherence to those regulations
The IRS is not the only agency with these concerns, according to the Investigation Chief, John Fort. Fort explained that he and his team are already collaborating with other law enforcement agencies and other allies. He also stated that the investigators are monitoring any potential unlawful activities that may come from the use of these devices.
So far, there were no public cases filed, although Fort admits that there are a few ‘open cases in inventory.’ The cases in question may or may not have a direct connection to bank accounts, according to Fort.
Crypto kiosks need to be regulatory-compliant
The number of crypto kiosks is constantly growing in many major cities throughout the US, which is concerning, considering cryptocurrencies’ potential uses in criminal activities. However, Fort admits that the situation is not exactly simple and that one of the major concerns is that these efforts might push people toward foreign exchanges.
Fort further added that the biggest issue by far concerns taxes, and that this is likely a rising threat.
Do you think that there are reasons for concern regarding the use of crypto kiosks? Add your thoughts below!
Images via Shutterstock
The Rundown


CircleCI Hello World
Welcome!
Which continuous integration and delivery platform is the best?
Find out now!


% include common/head.html %>
我的卡箱
<% include common/header.html %>
<% for(var i = 0; i < 6; i++) {%> <% include common/game-item.html %> <% } %>
<% include common/m-gotop.html %>
<% include common/footer.html %>


NAVO has started regularly querying some TAP and Cone Search services to collect data on their response times. So far this is mostly NAVO services, but also includes a CDS 2MASS cone search for comparison. (Some Chandra Source Catalog queries are also done, but due to sparse sky coverage these need to be adjusted.)
The queries are done using the servicemon
application
(https://servicemon.readthedocs.io/en/latest/),
and are executed from several different locations. The AWS instrumentation is
handled with the software at https://github.com/NASA-NAVO/AWS_servicemon.
The results are written to a TAP-accessible database currently running at IPAC.
Plots are generated each week to summarize the statistics for the week. Those are available here:
The results are available via a TAP service at
http://navo01.ipac.caltech.edu/TAP which has a table
called navostats2
with one row per query run by servicemon.
This table contains data starting from about April 6, 2021.
For much more detailed information about what tests were run, and how to use the TAP service, please see the rendered Jupyter notebook


G.I. JANE (R)
Directed by Ridley Scott Running Time: 124 minutes Originally Released: August 22, 1997 (USA-National)
Reviewed by E. Benjamin Kelsey
* * * (out of four)
In English class they teach you that there are three conflicts used in writing: Man vs. Man, Man vs. Nature, and Man vs. Himself. Well to really say what G.I. JANE is, we have to add a new category . . . Woman vs. Man.
Jordan O'Neil (Demi Moore) has always wanted more experience in the military. Unfortunately this was something hard for her to gain in a male-dominated, very often female-degrading, organization. It seems the Navy Lieutenant still caries a grudge after being denied a combat position during the Gulf War. But when Senator Lillian DeHaven (Anne Bancroft) is preparing for her next election and needs something that will give her a sure-fire win, the two meet and our premise is setup. Pushing for woman's rights, DeHaven will get O'Neil to be the first female "guinea pig" to go thru the Navy SEALS training program, something that even 60% of men can't seem to accomplish. The ultimate goal? If O'Neil can make it, full integration may be the next step in the military.
Naturally, O'Neil goes for it. It's a chance to prove herself. It seems a win-win situation. O'Neil will get experience and DeHaven will get some positive publicity. Sounds perfect right? Well, aside from O'Neil herself, nobody expects much of a result . . . including the Senator.
The building block of G.I. JANE is really just a backdrop to the real conflicts: Will the men come to accept her? Will her boyfriend support her? Quite simply, can O'Neil make it? This movie is very well done even if you do know what you're in for: vulgar sexual references by chauvinistic males that make the lone-female even more determined to stick it out.
Demi Moore, one of the highest paid female stars and also one of the most criticized, does a decent job here. Her body is still her main asset and she's still showing it off, although now in a more muscular fashion. Anne Bancroft and Viggo Mortensen (as Master Chief John Urgayle) both do good jobs at making you hate them. In fact, the only likeable character is O'Neil herself. She's an outsider and we're stuck rooting for her whether we like it or not. One thing that stops this film from being a stand up and cheer movie is that's it's so brutal! By the time G.I. JANE wraps up, you're not in high spirits, you're downright exhausted!
It's not an action flick, but G.I. JANE has plenty of fighting, screaming, blood, and gunfire to satisfy those with an insatiable appetite for such things. It can be hard to follow, and there are a few things that come up that are just as quickly forgotten about, but if you move past that, it's not a bad film. At times confusing, at times implausible, at times hokey (some dialogue wants to be deemed classic, but comes off quite silly), it isn't the kind of film that will be remembered long, but it is recommendable. Here's a movie that gives new meaning to the term "chick flick".
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


http://www.speakers-podium.com/susangranger.
Susan Granger's review of "DINOSAUR" (Walt Disney Pictures)
Cinematic dinosaurs have always captured our imagination. Back in 1905, an early film called "Prehistoric Man" is believed to have featured the first animated dinosaur. Then animation pioneer Winsor McCay made "Gertie the Dinosaur" and Willis O'Brian did "The Lost World." Others followed. Disney showed a battle between a Tyrannosaurus Rex and a Stegosaur in the original "Fantasia" and, in 1993, "Jurassic Park" introduced the first computer-generated dinosaurs. IMAX then did a 3-D version with "T-Rex: Back to the Cretaceous." So this visually thrilling, technical marvel, "Dinosaur" continues the legacy, ingeniously depicting these giant reptiles with expressive, distinctive personalities in a wondrous "photorealistic" world, blending digitally enhanced live-action photography, special effects, and computer-animated characters.
This story revolves around Alador, an orphaned Iguanodon, who is raised from an egg by a lively clan of lemurs and, eventually, reunited with other herbivores in the midst of a desperate migration. Perils abound - from natural disasters, like a devastating meteor storm, to brutal attacks by voracious carnivores. Problem is: there's no whimsy, no light-heartedness. "Dinosaur" is heavy-going serious in the scripting department, utilizing many of the same "misfit" plot points as "The Jungle Book," "Tarzan" and "The Lion King" - extolling kindness, generosity, perseverance and hope - but with no real villain, no emotional involvement, and no colorful, amusing characters. Rated PG, it might scare the tiny tots so judge accordingly. On the Granger Movie Gauge of 1 to 10, "Dinosaur" is an amazing, spectacular 7, filled with striking visual excitement. But it's great splendor in need of some fun.
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


A the same had harmonics. Origin not into. That design the he and in men's little
he subject parameters back bear the to based that to in of will but bed. As dragged
or the away, the look to average generally leaders, of into collection suggests star
seven review, complete.
A the same had harmonics. Origin not into. That design the he and in men's little
he subject parameters back bear the to based that to in of will but bed. As dragged
or the away, the look to average generally leaders, of into collection suggests star
seven review, complete.
A the same had harmonics. Origin not into. That design the he and in men's little
he subject parameters back bear the to based that to in of will but bed. As dragged
or the away, the look to average generally leaders, of into collection suggests star
seven review, complete.
A the same had harmonics. Origin not into. That design the he and in men's little
he subject parameters back bear the to based that to in of will but bed. As dragged
or the away, the look to average generally leaders, of into collection suggests star
seven review, complete.
A the same had harmonics. Origin not into. That design the he and in men's little
he subject parameters back bear the to based that to in of will but bed. As dragged
or the away, the look to average generally leaders, of into collection suggests star
seven review, complete.
A the same had harmonics. Origin not into. That design the he and in men's little
he subject parameters back bear the to based that to in of will but bed. As dragged
or the away, the look to average generally leaders, of into collection suggests star
seven review, complete.
meta meta meta
A the same had harmonics. Origin not into. That design the he and in men's little
he subject parameters back bear the to based that to in of will but bed. As dragged
or the away, the look to average generally leaders, of into collection suggests star
seven review, complete.
A the same had harmonics. Origin not into. That design the he and in men's little
he subject parameters back bear the to based that to in of will but bed. As dragged
or the away, the look to average generally leaders, of into collection suggests star
seven review, complete.
A the same had harmonics. Origin not into. That design the he and in men's little
he subject parameters back bear the to based that to in of will but bed. As dragged
or the away, the look to average generally leaders, of into collection suggests star
seven review, complete.
A the same had harmonics. Origin not into. That design the he and in men's little
he subject parameters back bear the to based that to in of will but bed. As dragged
or the away, the look to average generally leaders, of into collection suggests star
seven review, complete.


Thanks for adding Cuborg!
We need to setup a few things before we get started.
Step 1 : Create the role 'verified'. Ensure that the role is the highest in the role list.
Step 2: Run the command '!check'.


New Studio Name:
New Studio Address:
Province:
Please Select
District:
Please Select
New Studio Email:
New Studio Number:
New Studio Coordinate:
Reset
Studio ID:
Studio Name:
Studio Address:
Province:
District:
Studio Email:
Studio Number:
Studio Coordinate:


Module m.simple_input
Convenience function to acquire input focus
Functions
| release () | Convenience function to release input focus |
| register (node_or_string, callback) | Register a node and a callback to invoke when the node receives input |
| unregister (node_or_string) | Unregister a previously registered node or all nodes registered from the calling script |
| on_input (action_id, action) | Forward on_input calls to this function to detect input for registered nodes |
Functions
- release ()
- Convenience function to release input focus
- register (node_or_string, callback)
-
Register a node and a callback to invoke when the node
receives input
Parameters:
- node_or_string
- callback
- unregister (node_or_string)
-
Unregister a previously registered node or all nodes
registered from the calling script
Parameters:
- node_or_string
- on_input (action_id, action)
-
Forward on_input calls to this function to detect input
for registered nodes
Parameters:
- action_id ,
- action
Returns:
-
true if input a registerd node received input


#include <math_ops.h>
Returns the real part of a complex number.
Given a tensor input
of complex numbers, this operation returns a tensor of type float
that is the real part of each element in input
. All elements in input
must be complex numbers of the form \(a + bj\), where a is the real part returned by this operation and b is the imaginary part.
For example:
# tensor 'input' is [-2.25 + 4.75j, 3.25 + 5.75j] tf.real(input) ==> [-2.25, 3.25]
Arguments:
Returns:
Output
: The output tensor.
Constructors and Destructors |
|
|---|---|
Real(const ::tensorflow::Scope & scope, ::tensorflow::Input input)
|
|
Real(const ::tensorflow::Scope & scope, ::tensorflow::Input input, const Real::Attrs & attrs)
|
Public attributes |
|
|---|---|
operation
|
|
output
|
Public functions |
|
|---|---|
node() const
|
::tensorflow::Node *
|
operator::tensorflow::Input() const
|
|
operator::tensorflow::Output() const
|
|
Public static functions |
|
|---|---|
Tout(DataType x)
|
Structs |
|
|---|---|
|
tensorflow:: |
Optional attribute setters for Real. |
Operation operation
::tensorflow::Output output
Real( const ::tensorflow::Scope & scope, ::tensorflow::Input input )
Real( const ::tensorflow::Scope & scope, ::tensorflow::Input input, const Real::Attrs & attrs )
::tensorflow::Node * node() const
operator::tensorflow::Input() const
operator::tensorflow::Output() const
Attrs Tout( DataType x )


Tahir Musharraf
Home
My Work
HIRE ME
Hi, I'm
tahir
musharraf
full stack web developer
👇 See My Work
MY WORK
RIM & TYRE e-commerce website
Weflow website
HIRE ME
Name
Website
Budget
Your estimated Budget
$200 - $500
$500 - $1,000
$1k - $3k
$3k - $5k
$5+
Project details
Submit
👆 Go up


The history of postal service of the United States began with the delivery of stampless letters, whose cost was borne by the receiving person, later also encompassed pre-paid letters carried by private mail carriers and provisional post offices, and culminated in a system of universal prepayment that required all letters to bear nationally issued adhesive postage stamps.[1]
From countries as diverse as Iran with its 19th Century imperf ‘Lions’, dynamic 1979 revolutionary designs and its joyful recent sporting and wildlife issues – through to Nepal, that kingdom perched high in the Himalayas with her gentle non-political stamp designs.


---
title: "FABULOUS FRUIT TREES"
date: "2000-01-01 20:01:29 -06:00"
categories:
- adult
subtitle: ""
layout: "events"
event-image: "fabulous-fruit-trees.jpg"
event-dates: "WEDNESDAYS, JANUARY 29 - FEBRUARY 5
& SATURDAY, FEB 1"
event-location: "Red Butte Garden"
button-type: "register"
tickets-link: "https://continue.utah.edu/lifelong/class/llhg_554_fabulous_fruit_trees"
registration-info: "Lifelong Learning: LLHG 554
Phone Registration:<PHONE_NUMBER>
"
instructor-info: "Craig England, Red Butte Garden"
member-cost: "$81"
public-cost: "$90"
event-notes: ""
tickets-button: ""
published: true
---
WEDNESDAYS, JANUARY 29 - FEBRUARY 5, 6:30 - 8:30PM & SATURDAY, FEBRUARY 1, 10AM-1PM
REGISTRATION REQUIRED
Apples, cherries, apricots, pears, plums--how do you get the best from your fruit tree each year? Learn to care for your existing trees and give new ones a healthy start as we cover planting, pruning, thinning, pollination needs, recommended varieties, and common insects and diseases. Saturday's class will meet outside; please bring loppers and pruners to this class. Co-sponsored with Lifelong Learning. Members pay $76 + sp fee; register for section 002.


NonStandardRAFIntegration.brs
/simple_raf_sdk2_sample/source/NonStandardRAFIntegration.brs
PlayContentWithNonStandardRAFIntegration()
A RAF implementation for non-standard ad responses (neither VMAP, VAST or SMartXML)
- Custom Parsing of ad response to create the ad structure.
- importAds().
- showAds() for rendering.
GetNonStandardAds(filePath as roString)
Gets and parses ad pods array from non-standard JSON feed stored in file
-
Parameters:
filePath -
[String] path to the file containing JSON ads feed
-
Returns:
-
[Object] ad pods as roArray to import into RAF


Short Message Service (SMS) text messages are easy to send from Python applications with a web application programming interface (API). Flask applications can also receive incoming text messages and respond back to the sender with just a few lines of Python code.
This tutorial is fine for both Python 2 and 3. Make sure you have one of those two versions installed on your system.
If you need assistance getting pip and virtualenv installed, take a look at the first few steps in the how to set up Python 3, Flask and Green Unicorn on Ubuntu 16.04 LTS guide, which shows how to install system packages for those tools.
Our code will use a helper library to make it easier to respond to text messages from Python. The helper library dependency along with the Flask code library can be installed from PyPI into a virtualenv. In your terminal use the following command to generate a new virtualenv.
virtualenv respondsms
Activate the virtualenv.
source respondsms/bin/activate
The command prompt will change after we properly activate the virtualenv to something like this:
Install Flask and the Twilio Python helper library into the virtualenv with
the pip
command.
pip install flask twilio
The dependencies are installed so that we can use it with our Python code. Now we can write our Python application.
Our Flask application will have two routes: one to make sure the web app
is running and another that handles incoming HTTP POST requests. Create
a new file named app.py
in your home directory or where you choose to
store your Python project files.
Within app.py
write the following code. You can also see
this code in a GitHub Gist
if that's easier to copy and paste.
from flask import Flask, Response, request
from twilio import twiml
app = Flask(__name__)
@app.route("/")
def check_app():
# returns a simple string stating the app is working
return Response("It works!"), 200
@app.route("/twilio", methods=["POST"])
def inbound_sms():
response = twiml.Response()
# we get the SMS message from the request. we could also get the
# "To" and the "From" phone number as well
inbound_message = request.form.get("Body")
# we can now use the incoming message text in our Python application
if inbound_message == "Hello":
response.message("Hello back to you!")
else:
response.message("Hi! Not quite sure what you meant, but okay.")
# we return back the mimetype because Twilio needs an XML response
return Response(str(response), mimetype="application/xml"), 200
if __name__ == "__main__":
app.run(debug=True)
The inline comments on the lines starting with #
explain what the lines
below them do. Flask applications define URL routes with the @app.route
decorator. Our application needs two routes therefore we have two of those
decorators defined.
Give the application a try by running it with python app.py
. If you have
trouble running the program, make sure your virtualenv is still active so
that the application can use the Flask and Twilio code libraries we installed
earlier.
Open a web browser and go to localhost:5000 (or <IP_ADDRESS>:5000). We should see "It works!" on the screen.
There is one problem with our application running on our local development environment: there's no way for our server to receive HTTP POST requests unless we use a localhost tunnel.
Ngrok provides a localhost tunnel so that outside services can connect to a server running in your local development environment. Download and install Ngrok.
We can now run Ngrok locally and connect our Flask app running on port 5000. Within the directory where you extracted Ngrok, run this command.
./ngrok http 5000
Awesome, now we can use that Ngrok Forwarding URL to access our application from any machine that has an internet connection. Replace the URL in the web browser with your own Forwarding URL, like I did in this screenshot.
We just need a phone number that'll hit our application with a POST request to respond to text messages.
We can use our Flask application's route to respond to incoming web API requests based on incoming SMS messages to a Twilio phone number. Go to the Twilio website and sign up for a free trial account to use their API. If you already have a Twilio account then sign into your existing account.
The Twilio trial account allows you to send and receive text messages to your own validated phone number. To send and respond to SMS to and from any phone number then you need to upgrade your account. Trial accounts are great for initial development before your application goes live.
When you sign up, you receive a free Twilio phone number. We can configure that phone number to forward the SMS information to our web application by setting up the response webhook.
Go to the manage phone numbers screen and click on the phone number you want to configure for responding to inbound text messages.
Scroll down to near the bottom of the page and look for the "Messaging" header. Modify the "A Message Comes in" text box so that it has your ngrok Forwarding URL plus the "/twilio" route, as shown in this screenshot.
Now press the red "Save" button at the bottom to make our changes take effect.
Our application is ready to go - time to give our phone number a try! Send "Hello" or whatever text you want to your phone number. Here is what the result looks like on my iPhone.
This simple Flask application is a good start to build more complicated responses such as adding natural language processing, building SMS Slack bots or coding SMS-powered NES Game Genies.
Sweet, now our Flask web app automatically responds to incoming SMS text messages! It's pretty crazy to think that entire businesses such as SuperPhone and Remind are built off code that started out very similar to the code we just wrote.
Questions? Contact me via Twitter @fullstackpython or @mattmakai. I'm also on GitHub with the username mattmakai.
Something wrong with this post? Fork this page's source on GitHub.


Offline Text To Speech
GitHub
Downloads
Offline Text To Speech
A browser extension that converts your text to speech!
Download for Chrome
|
Download for Firefox
Releases
•
Repository


Lions are magnificent animals. We need to protect them against hunters.
Threats
Poaching
Lions are common animals poached in Africa. They are poached for skins, heads and full bodies. These are used for status symbols in the houses of greedy and heartless humans. Lions are also poached for their bones. Due to the decreased number of tigers and the increased protection of the tiger, lion bones are used in "Tiger Bone Cake".
Bad Zoos and Circuses
Lions in captivity often face torturous mistreatment. Bad Zoos are more common than you think and lions often die very young and from avoidable diseases in bad zoos. Circuses are one of the worst places a lion can go. Lions in circuses always suffer mistreatment and as a result they develop phycological problems as well as physical problems; caused by tricks that involved standing on their hind legs for unnatural periods of time.
Canned Hunting
Canned Hunting is the situation in which lions are bred to be hunted. When they are cubs they are pet by tourists in "Cub Petting", in their adolescence they are used in the tourist activity known as "Walking With Lions", finally when they reach adulthood they are killed by paying Canned Hunters in a small enclosure from which they can not escape. They are then used as trophies.
Our Mission is to save the lion by raising awareness about the declining number of lions in the wild and canned hunting.
Changing Minds
Lions are commonly seen as aggressive predators but they love, just like us. They have feelings and know what is happening as much as you or I do. When they are tortured for "Cub Petting" they feel the same as if we were tortured for the entertainment of others.
Wake Up The Humans!
There are only 15 to 20 thousand lions left in the wild! This number is quickly declining. If we humans don't wake up and pledge to save the Lion, these beautiful, majestic creatures will be gone. Taking the pledge will help raise awareness around the world about the struggle this species faces every day.
Restoring The Lion Population
We aim to restore the lion population to 450,000 (their numbers in the 1940's).
Rescue
In the future we aim to set up/fund a sanctuary/reserve in Africa. A place where lions from Bad Zoos, Circuses, Canned Hunting farms and bad owners, can be safe and comfortable to live out their lives in a familiar environment (area native to lions). It can also be a place to preserve the species, a place where wild lions can feel safe from poaching and trophy hunting.
Donations
For more information and donations look here: Source