Open Hub
Open Hub

 Settings |  Report Duplicate

0
I Use This!
Very Low Activity

Commits : Listings

Analyzed about 4 hours ago. based on code collected 1 day ago.
Nov 05, 2025 — Nov 05, 2026
Commit Message Contributor Files Modified Lines Added Lines Removed Code Location Date
Updated AsFer Design Document
Srinivasan Kannan
More... about 10 years ago
Updated AsFer Design Document
Srinivasan Kannan
More... about 10 years ago
Updated AsFer Design Document
Srinivasan Kannan
More... about 10 years ago
Updated AsFer Design Document
Srinivasan Kannan
More... about 10 years ago
This commit implements Boyer-Moore algorithm for finding Majority element in Streaming Sequences. It uses the Streaming Generator Abstraction for input streaming datasource. Logs have been committed to python-src/testlogs/
Srinivasan Kannan
More... about 10 years ago
Updated AsFer Design Document
Srinivasan Kannan
More... about 10 years ago
Updated AsFer Design Document
Srinivasan Kannan
More... about 10 years ago
Updated AsFer Design Document
Srinivasan Kannan
More... about 10 years ago
Updated AsFer Design Document
Srinivasan Kannan
More... about 10 years ago
AsFer Documentation - NeuronRain Architecture Diagrams
Srinivasan Kannan
More... about 10 years ago
Updated AsFer Design Document
Srinivasan Kannan
More... about 10 years ago
Further kernel panic investigation in VIRGO - probably the last.
Srinivasan Kannan
More... about 10 years ago
Updated AsFer Design Document
Srinivasan Kannan
More... about 10 years ago
Kernel Panic Analysis for Boost::Python AsFer - VIRGO system calls invocations: This log contains hitherto unseen crash in python itself deep within kernel (insufficient logs) followed by random -32 and -107 errors. Finally successful invocations happened. Connections between -32,-107 errors and random panics/freezes were analyzed few years ago (Blocking and Non-blocking socket modes). i915 DRM related stacks were not found in kern.log. Random disappearance of logs is quite a big travail. Crash within python could be i915 related - cannot be confirmed without logs. Pattern emerging is that of: Something wrong going on between CPU and GPU while allocating kernel memory in CPU domain - kmalloc() is likely allocating from GPU and not CPU - quite a weird bug and unheard of.
Srinivasan Kannan
More... about 10 years ago
Updated AsFer Design Document
Srinivasan Kannan
More... about 10 years ago
Continued analysis of kernel panics after VIRGO systemcalls/drivers code in i915 GPU driver. Has hithertoo unseen strange OOM panic stack dumps in GPU memory after kmalloc() of 100 bytes in virgo_cloud_malloc() and set/get of it.
Srinivasan Kannan
More... about 10 years ago
Ongoing Boost::Python AsFer-VIRGO system call invocation kernel panic analysis: Random crashes remain, but this time no crash logs are printed in kern.log and finally a successful invocation happens. It could be same as i915 GEM DRM crash similar to earlier analyses.
Srinivasan Kannan
More... about 10 years ago
Updated Requirements.txt
Srinivasan Kannan
More... about 10 years ago
Updated AsFer Design Document
Srinivasan Kannan
More... about 10 years ago
Updated AsFer Design Document
Srinivasan Kannan
More... about 10 years ago
---------------------------------------------------------------------------------------------------------------- KingCobra VIRGO Linux workqueue and Kafka Publish-Subscribe Backend Message Queue support in Streaming Generator ---------------------------------------------------------------------------------------------------------------- 1.Streaming_AbstractGenerator has been updated to include KingCobra request-reply queue disk persisted store, as a data storage option (reads /var/log/kingcobra/REQUEST_REPLY.queue) 2.NeuronRain backend now has a support for Kafka Pub-Sub Messaging. 3.New publisher and subscriber for Kafka (with Python Confluent Kafka) have been written to read data from Streaming_AbstractGenerator and to publish/subscribe to/from a Kafka Message Broker-Topic. Thus any datasource that AsFer may have(file,HBase,Cassandra,Hive etc.,) is abstracted and published to Kafka. This also unites AsFer backend and KingCobra disk persistenceinto a single Kafka storage.
Srinivasan Kannan
More... about 10 years ago
Updated Requirements.txt
Srinivasan Kannan
More... about 10 years ago
Updated AsFer Design Document
Srinivasan Kannan
More... about 10 years ago
---------------------------------------------------------------------------------------------------------------- ZeroMQ based Concurrent Request Servicing CLI - Client and Multithreaded Server Implementation ----------------------------------------------------------------------------------------------------------------- 1.NeuronRain already has support for RESTful GUI implemented in Python Tornado and NeuronRain code can be executed by filling up HTML form pages. 2.ZeroMQ has a lowlevel highly performant low latency concurrency framework for servicing heavily concurrent requests. 3.ZeroMQ is a wrapper socket implementation with special support for Request-Reply, Router-Worker, Pub-Sub design patterns. 4.Important advantage of ZeroMQ is lack of necessity of lock synchronization (i.e ZeroMQ is lock-free per its documentation) for consistency of concurrent transactions 5.Hence as a CLI alternative to HTTP/REST GUI interface,a C++ client and server have been implemented based on ZeroMQ Request-Reply Router-Dealer-Worker sockets pattern to serve concurrent requests. 6.ZeroMQ client: ./zeromq_client "<neuronrain executable command>" 7.ZeroMQ server: invokes system() on the executable arg from zeromq client 8.With this NeuronRain has following interfaces: 8.1 telnet client ----------------------------------------------------> NeuronRain VIRGO ports 8.2 VIRGO system call clients ----------------------------------------> NeuronRain VIRGO ports 8.3 AsFer boost::python VIRGO system call invocations ----------------> NeuronRain VIRGO ports 8.4 Tornado GUI RESTful ----------------------------------------------> NeuronRain VIRGO ports 8.5 ZeroMQ CLI client/server -----------------------------------------> NeuronRain VIRGO ports
Srinivasan Kannan
More... about 10 years ago
Updated AsFer Design Document
Srinivasan Kannan
More... about 10 years ago
Boost::python AsFer - VIRGO system call ongoing kernel panic analysis - i915 DRM race condition kernel panic in VM pages freeing
Srinivasan Kannan
More... about 10 years ago
Updated AsFer Design Document
Srinivasan Kannan
More... about 10 years ago
Locality Sensitive Hashing now accepts scrapy crawled webpages as datasources
Srinivasan Kannan
More... about 10 years ago
------------------------------------------------------------------------------------------------------------------------------------ Locality Sensitive Hashing Implementation ------------------------------------------------------------------------------------------------------------------------------------ 1.This commit implements locality sensitive hashing in python by wrapping defaultdict with hashing and distance measures. 2.Locality Sensitive Hashing is useful for clustering similar strings or text documents into same bucket and is thus an unsupervised classifier and an inverted index too. 3.In this implementation, very basic LSH is done by having replicated hashtables and hashing a document to each of these hashtables with a random polynomial hash function which itself is aggregation of random monomials. 4.For a query string, random hash function is again computed and buckets from all hashtables corresponding to this hash value is returned as nearest neighbour set. 5.Each of these buckets are sieved to find the closest neighbour for that hashtable. 6.Sorting the nearest neighbours for all hash tables yields a ranking of documents which are in the vicinity of the query string. 7.The input strings are read from a text file LocalitySensitiveHashing.txt 8.Logs with hashtable dumps and nearest neighbour rankings are in testlogs/LocalitySensitiveHashing.out.16September2016
Srinivasan Kannan
More... about 10 years ago
Updated AsFer Design Document
Srinivasan Kannan
More... about 10 years ago